composer.lock冲突是依赖树真实不一致，非git误报；必须丢弃冲突文件，用composer update --lock重建，禁用手动编辑——因冲突标记会破坏json结构，字段顺序或哈希错乱将导致install失败或运行时异常。
composer.lock 冲突不是 Git 误报，是依赖树真实不一致；必须丢弃冲突文件、用 composer update --lock 重建，禁用手动编辑。
为什么不能手动解决 composer.lock 的 Git 冲突
冲突块里的 会直接破坏 JSON 结构，<code>composer install 立刻报 JSON decode error；即使侥幸解析成功，packages 数组顺序错乱、dist.sha256 哈希不匹配，会导致类加载失败或运行时行为不一致。Composer 不校验 lock 语法，只在 install/update 时重生成并比对——你改的不是文本，是依赖图的快照。
- 用
git checkout --ours强行保留某方 lock → 实际依赖状态已偏离对方composer.json，install可能失败或装出错误版本 - 删冲突标记、调缩进、用在线 JSON 工具“美化” → 字段顺序和空格被重排，触发大量“假冲突”，掩盖真实差异
-
composer update --lock不修复已有冲突，它会覆盖整个文件，丢失对方改动
冲突发生后最稳妥的重建流程
核心是放弃冲突的 composer.lock 文件本身，以双方 composer.json 合并后的最终状态为唯一可信源，让 Composer 重新生成 lock。
- 先
git fetch origin && git merge origin/main（或rebase），确保composer.json已整合双方变更（如新增"monolog/monolog": "^3.0"） - 删掉本地
vendor/和composer.lock（避免残留缓存干扰） - 运行
composer update --no-install：只更新 lock，不重装vendor，检查输出里是否出现非预期的降级或跳过包 - 确认无误后
git add composer.lock并提交，附带清晰描述（如"lock: sync monolog ^2→^3 + fix php 8.3 platform constraint"）
怎么从源头大幅减少 composer.lock 冲突频率
高频冲突本质是多人无序修改依赖。关键不是限制操作，而是统一节奏和验证点。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 所有依赖变更必须先改
composer.json，立即执行composer update --lock，一起提交——禁止只提json不提lock - 在
composer.json里加"config": { "sort-packages": true }，强制包列表按字母序排列，大幅减少“假冲突” - CI 流程中加校验：
composer install --dry-run失败即阻断，倒逼开发者先拉最新composer.lock再提交 - Git 配置
composer.lock merge=ours（写入.gitattributes）可避免自动合并，但不能替代人工同步json
composer install --no-lock 是定时炸弹，别在 CI 里用
有些团队为绕过 lock 冲突，在 CI 脚本里写 composer install --no-lock，结果上线环境装的包和本地开发机完全不一致——安全补丁没上、间接依赖升级引发兼容问题、半夜报错根本无法复现。
正确做法是 CI 始终用 composer install --no-interaction，并确保检出代码时 composer.json 和 composer.lock 严格匹配。一旦提示 lock file is not up to date with composer.json，说明 PR 提交者漏跑了 composer update --lock，应直接拒绝合并。
真正难的不是重建 lock，而是让所有人理解：它不是配置文件，是构建指纹；冲突时不是“选谁的版本”，而是“共同确认当前依赖树该长什么样”。
