生产环境必须用 composer install 而不是 composer update，因为 composer.lock 锁定确切版本确保依赖一致；update 会忽略锁文件、拉取未测试版本，易致线上崩溃。
为什么生产环境必须用 composer install 而不是 composer update
因为 composer.lock 文件锁定了所有依赖包的确切版本号（包括子依赖），composer install 会严格按这个文件安装，确保每次部署的依赖完全一致。而 composer update 会忽略 composer.lock，重新解析 composer.json 并拉取最新兼容版本，极易引入未测试过的变更，导致线上行为不一致甚至崩溃。
composer install 在生产环境的正确执行方式
默认情况下，composer install 会安装开发依赖（require-dev）并生成自动加载优化文件，这在生产环境既不安全也不必要。必须显式禁用：
- 加
--no-dev：跳过require-dev中的包（如phpunit、mockery） - 加
--optimize-autoloader（或简写-o）：生成类映射（classmap），避免运行时遍历目录查文件，提升自动加载性能 - 加
--no-interaction（或简写-n）：防止交互式提示中断自动化部署流程 - 不加
--ignore-platform-reqs：除非你明确知道 PHP 或扩展版本不匹配且已验证兼容，否则跳过该参数，避免因平台限制缺失引发运行时错误
composer install --no-dev --optimize-autoloader --no-interaction
部署前必须检查的 3 个关键点
很多线上问题其实源于部署前疏忽，而非命令本身：
-
composer.lock必须已提交到 Git：CI/CD 拉取的代码里如果没有这个文件，composer install会退化为update行为，等同于没锁 - 确认当前 PHP 版本与
composer.lock中记录的构建环境一致：不同 PHP 大版本（如 7.4 vs 8.1）可能导致某些包的platform-check失败，报错类似Your platform does not meet the requirements... - 清理旧的
vendor/和composer.phar缓存：CI 环境若复用容器或缓存，残留的旧 vendor 或过期的 Composer 二进制可能干扰安装逻辑，建议部署脚本开头加rm -rf vendor/和composer clear-cache
常见报错及对应解法
遇到报错别急着搜“composer install failed”，先看错误关键词定位根源：
-
file_put_contents(./composer.json): failed to open stream: Permission denied：说明当前用户对项目目录无写权限，不是 Composer 问题，是部署用户权限配置错误；应确保运行命令的用户对vendor/、composer.json、composer.lock均有读写权 -
Class XXX not found且刚执行完install -o：大概率是--optimize-autoloader导致某些动态加载逻辑失效（如基于文件名反射的包），临时改用--classmap-authoritative更严格，或回退到--optimize-autoloader+ 检查是否漏了autoload配置 -
Failed to download xxx/yyy: The "https://api.github.com/..." file could not be downloaded：私有包或 GitHub 限流，需配置auth.json并确保 token 有效，或启用--prefer-dist强制走压缩包而非源码克隆
最常被忽略的是：本地 composer install 成功 ≠ 生产环境一定成功。锁文件的平台信息、扩展可用性、文件系统大小写敏感性（Linux vs macOS）、甚至 umask 设置，都可能让同一行命令在线上失败。
