根本原因是执行了 composer update 或删除了 composer.lock；只要 lock 文件存在且未被绕过，install 必然严格按其还原依赖——这是 composer 的设计契约。
为什么 composer install 有时装的不是 composer.lock 里的版本
根本原因只有一条：你执行了 composer update（或没加 --no-dev 却在生产环境跑了它），或者有人手动删了 composer.lock。只要 composer.lock 存在且没被绕过，composer install 就只会严格按它还原依赖——这是 Composer 的设计契约，不是“大概率”而是“必然”。
常见错误现象：
- CI/CD 流水线里用了
composer update而非composer install，导致每次构建都拉最新小版本 -
composer.json中写了"monolog/monolog": "^2.0"，但composer.lock里锁的是2.10.0；某天本地运行composer update monolog/monolog，锁文件升级到2.11.0，却没提交 lock 文件 - Git 忽略了
composer.lock（比如误配了.gitignore），导致协作时每人跑一遍install都得到不同结果
composer.lock 必须进 Git，且不能被忽略
这是最常被轻视的硬性规则：composer.lock 不是“可选缓存”，它是生产一致性的唯一凭证。没有它，composer install 和 composer update 行为完全等价。
实操建议：
- 检查
.gitignore是否意外包含composer.lock—— 它不该出现在那里 - 团队首次接入时，确保
composer install后立刻git add composer.lock并提交 - 如果历史提交漏了 lock 文件，用
git add -f composer.lock强制加入，再推送到远程 - CI 环境必须先
git pull拉取最新的composer.lock，再运行composer install --no-interaction --no-progress
什么时候该用 composer update，什么时候只能用 composer install
composer install 是部署和协作的默认命令；composer update 是主动变更依赖的“编辑操作”，应有明确意图、代码审查和测试覆盖。
使用场景与风险：
- 开发新功能需升级某个包？先
composer update vendor/package-name（指定包），再验证，再提交更新后的composer.lock - 安全扫描提示某依赖有 CVE？优先尝试
composer update vendor/package-name --with-dependencies，避免全量更新引发意外 - 执行
composer update无参数？等于允许所有依赖升到composer.json允许范围内的最新版——这极易引入不兼容变更，尤其跨次版本（如^3.0升到4.0） - CI/CD、Docker 构建、线上部署脚本里出现
composer update？立刻改成composer install，否则锁定失效
CI 和 Docker 中防止漂移的关键配置
Docker 构建层缓存、CI 缓存机制容易掩盖 lock 文件未生效的问题。关键不是“快”，而是“准”。
实操要点：
- Dockerfile 中，
COPY composer.json composer.lock ./必须在RUN composer install之前，且两者不能合并成一行（否则缓存失效逻辑错乱） - CI 脚本里，加上校验步骤：
composer show --locked | head -n 5或比对composer.lock的 git hash，确认没被意外修改 - 若项目含
platform配置（如"php": "8.1"），确保 CI 环境 PHP 版本与之匹配，否则composer install可能静默降级兼容版本 - 私有包场景下，
composer config --global repos.packagist.org.allow_ssl_downgrade false这类配置要统一，避免因源配置差异导致解析出不同版本
真正难的不是写对命令，而是让所有人——包括刚入职的同事、临时介入的运维、甚至半年后回看的自己——在任何环节都不会无意中绕过 composer.lock。它脆弱，但有效；它沉默，但不容妥协。
