composer.lock冲突必须丢弃重建而非手动解决，因其是依赖快照，含Git冲突标记、字段顺序/缩进差异、platform环境不一致等均会导致JSON解析失败或hash不匹配。

composer.lock 文件冲突不能手动解决，必须丢弃并重建——它不是配置文件，是依赖快照，改错一个逗号就可能让 composer install 静默装错包。

为什么一 merge 就报 JSON decode error

Git 冲突标记（<<<< HEAD、=======、>>>> origin/main）本身就会破坏 JSON 结构，composer install 直接拒绝解析。即使你手动删掉这些标记，还有更隐蔽的问题：

• packages 数组顺序不同 → content-hash 计算结果不一致 → 后续 composer install 报 Package xyz has a mismatched hash
• 缩进、空行、字段顺序被调整 → Git 触发“假冲突”，掩盖真实依赖差异
• platform 字段（如 "php": "8.2.0"）因本地 PHP 版本不同而自动变更 → 两边 lock 看似只差一行，实则环境语义已分裂

冲突发生后三步重建流程

前提是：你已经手动合并或 git checkout --ours/--theirs 整合好了 composer.json，且确认它语义正确（比如新增了 "monolog/monolog": "^3.0"）。

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

• 删掉当前冲突的 composer.lock（可先 mv composer.lock composer.lock.bak 备份）
• 运行 composer update --lock —— 注意不是 install，也不是 update 全量更新；它只读 composer.json，重写 lock 结构，不改任何包版本
• 检查输出：理想状态是 Lock file operations: 0 installs, 0 updates, 0 removals；如果出现大量 Updating xxx，说明 composer.json 还没真正拉齐，得先 git pull origin main 再来

CI 和本地环境不一致？先看 platform 和扩展

同一份 composer.lock 在 CI 失败、本地却能跑通，大概率不是 lock 问题，而是环境校验不一致：

• 运行 composer show --platform，对比所有人输出的 php、ext-intl、lib-curl 是否一致
• 若不一致，别急着删 lock，先统一 Dockerfile 或 .php-version；否则 composer update --lock 生成的仍是“带偏见”的快照
• 用 composer why-not vendor/package:2.1.0 定位阻断源——A 机器报 requires php ^8.1，B 机器报 requires ext-gd，分歧点立刻浮现

怎么让冲突少一点

高频冲突本质是多人无序修改依赖。预防比修复更重要：

• 在 composer.json 加 "config": { "sort-packages": true }，再跑一次 composer update --lock 提交，消除因包顺序导致的“假冲突”
• 禁用 composer update 全量更新，改用 composer update vendor/package-name --with-all-dependencies 精确控制影响范围
• CI 中加 composer install --dry-run 校验：失败即阻断合并，逼团队养成“改完 composer.json 就立刻 update --lock”的习惯

最常被忽略的一点：composer.lock 的价值不在它“看起来一样”，而在它能被所有目标环境稳定解析并还原出完全一致的 vendor/。重建时若跳过 composer show --platform 核对，或绕过 --dry-run 验证，等于把问题藏到上线前才爆发。