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 也救不回一致性。










