composer.lock是协作中依赖版本的唯一权威来源，必须与composer.json同步提交，否则会导致环境不一致、Class not found等故障；它记录精确版本、校验值和平台信息，确保可重现构建。
锁文件（composer.lock）不是“可选附件”，而是协作中包版本事实的唯一权威来源；任何未同步 composer.lock 的提交，都会导致队友执行 composer install 时还原出不同依赖树。
为什么 composer.lock 变动必须和 composer.json 更新一起提交
团队里常见错误是：改了 composer.json 中某个包的版本号，运行 composer update foo/bar，但只提交了 composer.json，漏掉 composer.lock。结果是：
- CI 流水线或队友本地执行
composer install时，仍按旧composer.lock安装——根本没用上你声明的新版本 - 如果旧
lock文件里还存着已删除包的残留记录，composer install可能静默跳过缺失依赖，引发运行时Class not found - Git 差异里看不到实际安装了什么，审计、回滚、复现环境都失去依据
正确做法永远是：composer.json 和 composer.lock 视为原子对，二者必须同时 add & commit。
区分 composer update 和 composer install 的适用场景
这两个命令在协作中承担完全不同的角色，混用会直接破坏环境一致性：
-
composer install：仅用于 CI、部署、新成员克隆后首次构建——它严格按当前composer.lock还原依赖，不读取composer.json的版本声明 -
composer update：仅用于主动升级依赖（如修复安全漏洞、引入新特性），且必须由明确责任人执行，并确保：- 先
git pull拉取最新composer.lock - 运行
composer update vendor/package --with-dependencies（避免半更新状态） - 检查生成的
composer.lockdiff，确认无意外变更（比如间接升级了 PHP 版本要求） - 提交
composer.json+composer.lock+ 相关兼容性修改（如代码里新增的类引用）
- 先
如何从 composer.lock 追溯某次包更新的上下文
composer.lock 本身不带时间戳或提交信息，但它在 Git 历史里天然绑定每次变更。查一次具体包的更新路径，靠的是 Git 而不是 Composer：
- 用
git log -p --follow composer.lock | grep -A5 -B5 '"name": "monolog/monolog"定位某包首次出现或版本变更的提交 - 配合
git show COMMIT_HASH:composer.json查看当时composer.json中该包的约束写法（^2.9还是2.9.0？） - 注意：若多人并行改 lock，
git blame composer.lock会显示大量 “not committed yet” 行——这不是 bug，是因为 Composer 写入 lock 是全量覆盖，Git 无法做行级追踪
所以真正可靠的“更新历史”，不在 lock 文件内部，而在 Git 提交信息是否清晰（例如提交标题写明 chore(deps): update guzzlehttp/guzzle to v7.8.1 (CVE-2024-3435)）。
CI/CD 中必须禁用自动 composer update
很多团队为“省事”在 CI 脚本里写 composer update --no-interaction，这等于把构建环境的控制权交给网络和 packagist 当前状态：
- packagist 临时不可用 → 构建失败
- 上游发布了一个含 BC break 的小版本（如
symfony/console v6.4.10里悄悄改了某个接口）→ CI 通过但线上报错 - 不同分支跑 CI 时拉到不同版本 → 同一 tag 构建结果不一致，违反可重现性原则
正确姿势是 CI 只跑 composer install --no-interaction --prefer-dist，并确保仓库中始终存在有效、已提交的 composer.lock。升级动作必须人工触发、人工审核、人工合并。
最常被忽略的一点：当项目启用 platform-check 或自定义 platform 配置时，composer.lock 里会嵌入 PHP 版本等平台信息。此时哪怕只改了 composer.json 里的 config.platform.php，也必须重新 composer update 并提交 lock——否则队友用 PHP 8.2 开发，而 lock 里锁死的是 PHP 8.1 的兼容包，install 时不会报错，但运行时可能因函数不存在而崩溃。
