composer.lock 文件总在合并时冲突，因为它是精确依赖快照，每次 install/update 都重写全文件，导致 Git 行级差异大且无法语义合并；手动修改会引发安装错误，正确做法是删掉冲突文件后运行 composer install 重建。
composer.lock 文件为什么总在合并时冲突
因为 composer.lock 是二进制安全但文本形式的精确依赖快照，每次 composer install 或 composer update 都会重写整个文件——哪怕只改了一个包的小版本，哈希、时间戳、嵌套结构顺序都可能变。Git 看到的是大量行级变动，根本没法自动合并。
这不是配置问题，是设计使然：它本就不该被“手工编辑”，也不该指望 Git 合并逻辑理解它的语义。
冲突发生后别手动改 composer.lock
手动删行、调顺序、拼哈希？99% 会导致后续 composer install 报错，比如：Root composer.json requires package-x ^2.1, found package-x[dev-main, 2.0.0] but these were not loaded，或者更隐蔽的 autoloader 错乱。
正确做法只有一个：放弃当前 composer.lock，用权威源重建。
- 确保
composer.json已合并干净（这是唯一需要人工确认的文件） - 删掉本地冲突的
composer.lock - 运行
composer install—— 它会按当前composer.json生成全新 lock 文件 - 提交这个新生成的
composer.lock
团队协作中怎么减少 composer.lock 冲突频率
冲突少不等于不用管，而是把“谁更新依赖”这件事收口：
- 禁用
composer update在 CI/CD 或开发机上随意执行；统一由专人定期跑composer update --dry-run检查变更，再 PR 提交composer.json + composer.lock - 所有成员本地只运行
composer install（不是update），保证环境一致 - 如果必须临时加依赖，用
composer require vendor/package --no-update先写进composer.json，再统一install
注意：--no-update 不会动 composer.lock，避免引入不可控变更。
CI 流水线里遇到 lock 冲突怎么破
CI 报 composer install 失败，常见错误是：Your lock file does not contain a compatible set of packages。这说明 composer.json 和 composer.lock 对不上，通常因分支合并遗漏了 lock 更新。
别在 CI 脚本里加 composer update —— 这会让构建结果不可重现。
- CI 第一步加检查：
composer validate --strict，提前发现 json/lock 不匹配 - 修复方式同上：删 lock →
composer install→ 提交 - 把
composer.lock加进 PR 模板 checklist，强制人工确认
最麻烦的其实是“锁文件里混进了 dev 分支或本地路径 repo”，这种在 CI 根本拉不到，得翻 composer.lock 里 source 字段确认 type 是否为 git 且 url 是公开可访问地址。
