生产环境严禁运行composer update，必须仅执行composer install --no-dev --optimize-autoloader --no-interaction，严格依据已验证的composer.lock快照安装；所有依赖变更须在测试环境完成并提交更新后的lock文件。
生产环境不能直接运行 composer update
它会无视 composer.lock 重新解析整个依赖树，极可能引入不兼容变更或意外降级。线上更新必须基于已验证的 composer.lock 快照，靠 composer install 安装——不是靠 update 计算。
常见错误操作包括：
- 在生产机上改了
composer.json后直接跑composer update - 只提交
composer.json，没提交composer.lock，导致composer install实际行为等同于update - 用
--ignore-platform-reqs强行跳过 PHP 版本/扩展检查，掩盖真实运行风险
正确路径是：所有变更（含版本升级）必须在测试环境完成验证 → 提交更新后的 composer.lock → 生产环境仅执行 composer install --no-dev --optimize-autoloader --no-interaction。
composer install 没装对版本？先确认 composer.lock 是你要的那个
现象：明明回滚了 Git 分支，vendor/ 里还是新包，甚至报 Class not found。根本原因往往是 composer.lock 文件没同步回退。
排查与修复步骤：
- 运行
git status composer.lock，看是否为modified或未暂存状态 - 若已提交历史版本，用
git checkout HEAD~1 -- composer.lock恢复（或指定确切 commit hash） - 彻底清理旧安装：
rm -rf vendor/（Windows 请手动删除） - 再执行
composer install—— 此时它才真正只读lock、不碰composer.json - 验证：
composer show vendor/package输出的version字段，不是只看composer.json里的约束
想降级某个包？别改 composer.json 后跑 update
手动改 composer.json 的版本号再 composer update vendor/package，仍会触发依赖重解析，可能连带升级其他包，失控风险高。
安全降级唯一推荐方式是：
- 查目标版本是否存在：
composer show -a vendor/package，注意是否标abandoned - 执行：
composer require vendor/package:1.2.3 --with-all-dependencies - 若失败，立刻查冲突：
composer why-not vendor/package:1.2.3，它会指出哪个包锁死了上限 - 降级后必须确保
vendor/和composer.lock同步；否则 CI 或下次install仍按旧lock装
特别注意：--with-all-dependencies 不是可选项——漏加会导致子依赖版本错乱，且无提示。
PHP 版本不匹配导致升级失败？别硬降 PHP，先调 platform
报错如 This package requires php ^7.4 but your PHP version (8.2.0) does not satisfy that requirement，不是要你卸载 PHP 8.2，而是 Composer 在平台检查阶段就卡住了。
临时绕过（仅用于构建/部署阶段）：
- 在
composer.json的config段加："platform": {"php": "7.4.33"} - 再跑
composer update --with-all-dependencies，它会按声明的 PHP 版本做依赖解析 - 但注意：这只是“告诉 Composer 你假装在 7.4 环境下”，实际运行仍需对应扩展和语法兼容——该修代码的还得修
真正长期方案是升级项目代码适配新版 PHP，或明确锁定运行环境的 PHP 小版本（如 Dockerfile 中固定 php:8.1-apache），而非靠 platform 掩耳盗铃。
