启用 "config": { "lock": true } 可强制校验 lock 文件一致性：若 composer.json 变更而 lock 未更新，install 直接报错退出，杜绝“改需求不更新快照”导致的版本混乱。
团队里依赖版本不一致、本地能跑线上报错、CI 构建失败——90% 是因为没把 composer.lock 当成核心契约，而不是“可有可无的缓存文件”。
为什么 composer install 在不同机器上装出不同版本？
这事儿，真不能怪 Composer 本身“不可靠”。问题的根源，往往是有人无意中绕过了 lock 文件的约束。具体来说，不外乎下面几种情况：
- 有人手动执行了
composer update，但提交代码时，偏偏忘了把新生成的composer.lock一起推上去。 composer.lock被错误地列在了.gitignore里，或者被 Git 的skip-worktree标记给“屏蔽”了。- CI 脚本里图省事，写了
composer update --no-interaction，以为“自动”就等于安全——殊不知，这个命令会直接无视现有的 lock 文件，重新计算依赖树。 - 本地开发环境的 PHP 版本或 Composer 版本和 CI 服务器不一致（比如 CI 用 Composer 2.5，本地还在用 1.10），导致 lock 文件的结构不兼容，解析出错。
所以，解决办法不是一遍遍“教育大家别乱点”，而是从机制上入手，让那些容易出错的操作根本走不通。
怎么让 composer install 拒绝装错版本？
答案其实很简单：启用 "config": { "lock": true } 这个配置。这是 Composer 2.2 及以上版本内置的“硬性校验”开关，效果立竿见影：
- 只要
composer.json有改动（比如新增了一个require），但composer.lock文件没有同步更新，那么执行composer install时就会直接报错退出，根本不给你安装错误版本的机会。 - 它并不阻止你升级依赖，它的核心使命只有一个：防止“改了需求却没更新快照”这种典型的低级失误。
- 当然，如果团队里还有人用着旧版 Composer（低于 2.2），这个配置就无法生效，统一工具版本是前提。
把这个配置项加进所有项目的 composer.json 里，比写一百遍团队文档都管用。
Git 提交前如何自动拦住漏更新 composer.lock？
指望开发者每次提交前都记得用肉眼检查 git status 是不现实的。更可靠的办法，是利用 Git 的 pre-commit 钩子进行强制校验：
- 脚本逻辑其实很清晰：如果检测到
composer.json被修改了（通过git status --porcelain | grep '^[AM] composer.json'判断），就立刻检查composer.lock是否也在本次提交的暂存区里（使用git ls-files --cached composer.lock）。 - 如果没找到？那就直接拒绝本次提交，并给出明确提示：
Run "composer update --lock" first。 - 这个钩子脚本放在项目根目录的
.git/hooks/pre-commit路径下，加上可执行权限就能生效。它不依赖任何全局工具，也不需要团队成员手动安装，真正做到开箱即用。
CI/CD 和部署脚本最容易漏掉的关键参数
除了 lock 文件，另一个线上事故的高频原因，是在生产部署时漏掉了 --no-dev 参数。这在 Symfony 或 Lara vel 这类框架项目中尤其危险：
- 如果不加
--no-dev，composer install会把phpunit、symfony/debug-bundle等开发依赖全部装进生产镜像。后果可能是：debug-bundle 暴露/_profiler等调试接口；像infection这类工具的 autoload-dev 规则，还可能意外污染生产环境的自动加载顺序。 - 因此，在 Dockerfile 或部署脚本中，命令应该固定写成：
composer install --no-interaction --optimize-autoloader --no-dev。 - 一个常见的实践是：在 CI 测试环境中使用完整安装（保留
require-dev的包），但在面向生产环境的部署脚本里，必须显式地带上--no-dev。别指望COMPOSER_ENV=prod这类环境变量能自动控制安装行为，它并不管这个。
话说回来，真正麻烦的往往不是参数本身，而是团队内部对“开发依赖是否会影响运行时”存在认知偏差。有些包看起来只是测试或构建工具，但实际上可能通过 autoload-dev 注入了运行时类。一旦混入生产环境，问题往往具有隐蔽性和延迟性，排查起来更加棘手。
