生产环境绝不能运行composer update，因其绕过composer.lock按composer.json重算依赖，可能引入未测试的补丁变更、破坏API兼容性或触发平台缺失错误；正确流程是开发端update并提交lock文件，生产端仅执行composer install --no-dev --optimize-autoloader。
生产环境绝不能运行 composer update，补丁升级必须走 composer install + 锁文件更新流程。
为什么不能在生产机上直接 run update
直接执行 composer update 会绕过 composer.lock 的版本锁定，根据 composer.json 中的版本约束（如 "^2.1" 或 "~3.4"）拉取最新兼容版本——哪怕只是个补丁号（3.4.1 → 3.4.2），也可能触发未验证的变更：比如某依赖悄悄改了方法签名、移除了废弃接口、或引入了新扩展依赖（如 ext-intl），而生产服务器没装。更危险的是，它会重写 composer.lock，若该文件意外被提交，就污染了整个团队的依赖快照。
常见错误现象：Class not found、Call to undefined method、Failed to open stream: No such file（指向 dev-only 脚本），基本都源于此。
补丁升级的正确路径：本地 update → 提交 lock → 生产 install
补丁级升级（例如修复安全漏洞 CVE-2026-XXXX 或紧急 bugfix）必须严格走“开发环境闭环”：
- 在干净的本地或 CI 构建机上运行
composer update vendor/package-name --with-dependencies，只更新目标包及其直系依赖，避免全量漂移 - 确认测试通过后，必须
git add composer.lock并提交——这是唯一可信的变更载体 - 部署时，在生产环境（或打包阶段）只执行
composer install --no-dev --optimize-autoloader - 若需跳过平台检查（如本地 PHP 8.2 → 生产 PHP 8.1），用
--ignore-platform-reqs，但应在composer.json的config.platform中显式声明目标版本，而非临时掩盖
如何防止误操作和自动化陷阱
CI/CD 流水线或运维脚本里藏的 update 是最大隐患。必须从四层拦截：
- 在部署脚本开头加校验：
grep -q '"version":' composer.lock || { echo "ERROR: composer.lock missing"; exit 1; } - 设置环境变量
COMPOSER_NO_INTERACTION=1和COMPOSER_DISABLE_XDEBUG=1，防交互卡住或 xdebug 导致 PHP 8.2+ 下 fatal error - Dockerfile 中固定使用多阶段构建：构建阶段
RUN composer install --no-dev --optimize-autoloader，运行阶段 COPY vendor/，彻底剥离composer命令 - 禁止生产服务器安装 Composer 二进制；若必须在线安装，确保
memory_limit=1536M且vendor/目录权限隔离（web 用户不可写）
补丁回滚比升级更关键
很多人只记得升，忘了退。一旦上线后发现补丁引发问题，最快恢复方式是：
- 立刻
git revert上次提交的composer.lock变更，再重新部署 - 不要试图在生产机上
composer update vendor/package-name:2.3.1—— 这仍会触发依赖树重解析，风险不可控 - 把历史
composer.lock文件按 tag 存档（如lock-v2.3.1.json），CI 构建时可指定cp lock-v2.3.1.json composer.lock && composer install
锁文件不是辅助文件，它是生产环境依赖的唯一真相源。任何绕过它的“快速修复”，都会让下一次故障更难定位。
