composer.lock不能自动合并，因其是依赖图精确快照，字段顺序、content-hash、platform等均有语义，Git冲突标记会导致JSON解析失败；正确做法是先确保composer.json无冲突，删除冲突lock，再运行composer update --lock重建。
composer.lock 不存在“自动合并工具”
它根本不能被安全地自动合并——不是工具没做出来，而是设计上就禁止这种操作。composer.lock 是依赖图的精确快照，字段顺序、content-hash、platform 字段全都有语义。Git 合并产生的 <<<< HEAD 和 >>>> origin/main 标记会让 json_decode() 直接失败，后续所有命令退出。
所谓“自动合并工具”，比如早年有人写的 composer-merge-plugin，早已停止维护，且官方明确不支持多源 lock 合并。它试图把 lock 当配置文件来 merge，逻辑本身就有缺陷。
git merge 时 composer.lock 冲突怎么处理
别碰冲突标记，也别选 ours/theirs 提交。正确流程是：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 先确认
composer.json已 clean merge（无冲突）——否则 lock 重建没意义 - 删掉当前冲突的
composer.lock（可先mv composer.lock composer.lock.bak备份） - 运行
composer update --lock：它不读旧 lock，只基于当前composer.json重新生成快照 - 如果输出显示
Lock file operations: 0 installs, 0 updates, 0 removals，说明依赖树一致；若出现大量Updating xxx，说明composer.json还没拉齐，得先git pull origin main
如何减少“假冲突”
很多标红其实不是依赖变了，只是格式扰动。两个关键配置能大幅降低干扰：
- 在
composer.json加"config": { "sort-packages": true }，再跑一次composer update --lock提交，消除因安装顺序不同导致的数组顺序差异 - 统一平台约束：
"config": { "platform": { "php": "8.2.0" } }，避免本地 PHP 版本浮动影响content-hash - 在项目根目录加
.gitattributes，写一行：composer.lock merge=ours，让 Git 冲突时直接采用当前分支版本（适合主干优先策略）
CI 构建失败时 lock 冲突的排查重点
CI 报错说 composer install 失败，90% 不是 lock 本身问题，而是环境校验不一致：
- 在 CI 和本地分别运行
composer show --platform，对比php、ext-intl、lib-curl是否完全一致 - 不一致时别急着重建 lock，先统一 Dockerfile 或 CI 运行时环境（比如固定 PHP minor 版本）
- CI 流程里加一步：
composer install --dry-run，验证 lock 是否与当前composer.json兼容；再加composer update --lock && git diff --quiet composer.lock || (echo "lock out of sync" && exit 1)，强制要求开发者提交前同步
真正复杂的地方不在怎么修 lock，而在于团队是否对 composer.json 的变更有共识、是否统一了平台约束、是否禁用了 Git 默认文本合并策略——这些才是 lock 冲突背后真正的协作断点。
