composer如何同步生产环境依赖_composer install –no-dev【实操】

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