composer.lock在git合并时爆红，是因为它不是配置文件而是依赖图的哈希快照，每次依赖操作都会全量重写；多人在不同分支执行composer update/require/remove导致json结构微小差异触发冲突；正确做法是用.gitattributes配置merge=ours或theirs策略禁用自动合并，并禁止feature分支随意执行update。
为什么composer.lock总在Git合并时爆红
它不是配置文件，是依赖图的哈希快照——每次composer update、composer require或composer remove都会重写整个文件。多人在不同分支上各自执行这些命令，Git 就会因 JSON 结构微小差异（比如哈希顺序、空格、字段位置）报冲突，哪怕实际依赖没变。
用.gitattributes禁用lock文件的自动合并
Git 默认把composer.lock当普通文本合并，结果产出非法 JSON。这不是 Composer 的问题，是 Git 配置没对。
- 在项目根目录新建
.gitattributes文件 - 写入一行：
composer.lock merge=ours（主干优先策略）或composer.lock merge=theirs（功能分支优先） - 提交该文件，后续所有 merge 冲突将自动采用指定版本，不再弹出冲突标记
这个配置比手动解决每次冲突快 10 倍，且杜绝了手改 JSON 导致语法错误的风险。
开发流程上卡死两个高危操作
90% 的 lock 冲突源于两类操作被滥用：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
composer update—— 禁止在 feature 分支里跑，它会无差别刷新所有依赖，放大差异 - 多人同时执行
composer require xxx或composer remove yyy—— 即使只增删一个包，lock 文件也会全量重写，极易撞车
正确做法是：所有依赖变更必须集中在一次提交，且仅用composer require/composer remove；合入主干前，在 feature 分支上先跑composer update --lock（不改依赖，只同步哈希），再提交。
CI/CD 构建失败前先查这三件事
很多构建失败其实和 lock 冲突无关，而是环境错配：
- 确认 CI 使用的 PHP 版本和本地一致，尤其注意
php平台约束是否写死了^7.4却在 PHP 8.0+ 环境跑 - 检查
composer.json里有没有repositories字段，它会屏蔽全局镜像配置，导致包拉不到 - 运行
composer diagnose，它会直接指出composer.lock是否损坏、vendor 是否缺失、平台扩展是否满足
lock 文件本身不决定能否装成功，真正起作用的是composer.json里的约束 + 当前运行环境 + 镜像源可用性。别一看到 build 失败就怀疑 lock 冲突。
