生产环境同步依赖必须执行三步：清空vendor、校验composer.lock一致性、运行composer install –no-dev –optimize-autoloader –no-interaction；仅用–no-dev不可靠，因它不校验vendor与lock是否匹配，且不检查PHP/扩展兼容性。
composer install –no-dev 不是生产环境同步依赖的可靠方式
它只跳过 require-dev 里的包，但完全不管 vendor/ 目录是否和 composer.lock 对得上。如果有人手删过某个包、用过 composer update、或者 vendor 被 CI 脚本污染过，composer install --no-dev 就会直接复用旧文件——表面成功，运行时报 class not found 或方法不存在。
- 真正同步 = 清空
vendor/+ 确保composer.lock和开发环境完全一致 + 重装 -
--no-dev是“不装 dev 包”，不是“重装非 dev 包” - CI/CD 中常见错误：在已有
vendor/的目录下直接跑这条命令，结果残留了上一版的monolog/monolog或symfony/console
生产部署前必须执行的三步组合动作
单条命令兜不住，必须按顺序做这三件事，缺一不可：
-
rm -rf vendor/—— 别信composer dump-autoload能救回来，autoload 文件只是映射，包本身可能已损坏或版本错乱 -
git diff composer.lock或比对sha256sum composer.lock—— 确认该文件和你本地测试/预发环境提交的完全一致（时间戳、哈希、内容） -
composer install --no-dev --optimize-autoloader --no-interaction——--optimize-autoloader生成静态类映射，避免运行时遍历；--no-interaction防止卡在 “Do you trust this repository?” 这类 prompt 上
为什么不能用 composer update –no-dev？
composer update --no-dev 会重新解析 composer.json、计算最新兼容版本、写新 composer.lock，等于悄悄升级所有非 dev 包——哪怕只是从 7.4.12 升到 7.4.13，也可能触发未测的 BC break。
-
install：读composer.lock→ 下载指定版本 → 不改 lock -
update --no-dev：读composer.json→ 解析约束 → 写新 lock → 下载 → 生产环境一旦执行，就等于绕过 QA 直接上线 - Dockerfile 里写
RUN composer update --no-dev是高危操作，很多线上事故源头在此
PHP 版本与扩展不匹配时，–no-dev 会静默失败
Composer 默认不校验当前 PHP 是否满足 composer.lock 里每个包声明的 php 或 ext-gd 要求，除非你显式开启检查。部署机 PHP 是 8.0，但 lock 里某个包要求 php: ^8.1？composer install --no-dev 会照常结束，直到第一次请求才报 Fatal Error: Uncaught Error: Call to undefined function mb_str_split()。
- 正确做法：部署机 PHP 版本、已启用扩展（如
ext-pdo_mysql、ext-xml）必须和composer.json中config.platform字段或各包的require.php对齐 -
--ignore-platform-reqs是临时绕过手段，不是解决方案；它可能装上根本跑不起来的包 - 建议在 CI 流水线加一步：
composer validate --strict+php -v && php -m | grep -E "mbstring|xml|ctype"
实际部署中最容易被忽略的，是 vendor/ 目录的“干净性”和 composer.lock 的“权威性”这两点。它们不是配置问题，而是流程契约——一旦松动，后续所有优化、缓存、自动加载都建立在流沙之上。