composer install --no-dev 不是生产环境同步依赖的可靠方式，因其仅跳过 require-dev 包，不校验或清理 vendor/ 与 composer.lock 的一致性；需先清空 vendor/、确认 lock 文件一致，再执行 install --no-dev --optimize-autoloader --no-interaction。
为什么 composer install --no-dev 在生产环境不是“同步依赖”的可靠方式
它只跳过 require-dev 里的包，但不会校验当前 vendor/ 是否和 composer.lock 完全一致。如果有人手动删过某个包、改过 vendor/、或用 composer update 混淆过环境，--no-dev 不会修复——它只是“不装开发依赖”，不是“重装所有依赖”。
- 典型错误现象：
composer install --no-dev执行很快、没报错，但运行时抛出Class not found或版本不匹配 - 真正同步的前提是：本地
composer.lock和目标环境的composer.lock内容一致，且vendor/是空的或已清理干净 - CI/CD 流水线里常见误操作：在已有
vendor/的目录下直接跑install --no-dev，结果残留了旧包
生产部署前必须做的三件事（缺一不可）
靠单条命令无法兜底，得组合动作。核心逻辑是：清旧 → 对齐锁文件 → 重装非 dev 包。
- 删掉整个
vendor/目录：rm -rf vendor/（别信composer dump-autoload能救回来） - 确认
composer.lock已提交且和开发环境一致（Git diff 看一眼composer.lock时间戳和 hash） - 执行
composer install --no-dev --optimize-autoloader --no-interaction：
•--optimize-autoloader生成静态映射，避免运行时扫描
•--no-interaction防止卡在 prompt（比如问你是否信任仓库）
composer install --no-dev 和 composer update --no-dev 的本质区别
前者按 composer.lock 安装，后者会重新解析 composer.json 并更新 lock 文件——生产环境绝对禁止后者。
-
install：读lock→ 下载指定版本 → 不改lock -
update --no-dev：读json→ 解析最新兼容版本 → 写新lock→ 下载 → 生产环境一旦执行，就等于悄悄升级了依赖 - 容易踩的坑：某些 Dockerfile 里写的是
composer update --no-dev，以为“不装 dev 就安全”，实则破坏了依赖锁定
PHP 版本和扩展不匹配时，--no-dev 会静默失败
Composer 默认不校验运行时环境是否满足包的 php 或 ext-xxx 要求，除非显式开启。
- 加
--ignore-platform-reqs是危险操作：它跳过所有平台检查，可能装上根本不能运行的包 - 正确做法：部署机 PHP 版本、已启用扩展（如
ext-gd,ext-pdo_mysql）必须和composer.json中config.platform.php或各包的require字段对齐 - 验证方法：本地用相同 PHP 版本跑一次
composer install --no-dev，看是否报Your requirements could not be resolved
vendor/ 目录的“脏状态”——它不像 Git 那样有 clean/dirty 概念，但影响比想象中更隐蔽。只要 vendor/ 里混着旧包，再严格的 --no-dev 也救不回一致性。 
