composer.lock 必须提交且冲突时不可手动编辑，它是依赖图的哈希快照；安全解决冲突的唯一方式是删掉 lock 和 vendor 后，以合并后的 composer.json 为唯一源执行 composer update --no-install 重建。
composer.lock 必须提交，且冲突时绝不能手动编辑——它不是配置文件，是依赖图的哈希快照；手动删冲突标记、凑版本、格式化 JSON，99% 会触发 install 失败或静默装错包。
为什么不能用 Git 工具“选 ours/theirs”解决 lock 冲突
Git 的 --ours 或 --theirs 是按文件行级选内容，但 composer.lock 里每个包的 dist.sha256、content-hash、嵌套依赖顺序都和 composer.json 全局状态强绑定。选错一边后：
- 保留了 A 分支的
laravel/frameworkv10.42.0，但 B 分支新增的spatie/laravel-ray在packages-dev里没被写入 →composer install报The lock file does not contain require-dev information - 选了
--theirs的 lock，但本地composer.json已删掉phpunit/phpunit→ install 时不会报错，却悄悄装出旧版 dev 包，CI 测试通过但本地跑不起来 - 字段顺序被 Git 自动重排（比如
name和version调换），导致composer validate通过，但后续composer update --lock会重写整块，掩盖真实变更
冲突发生后唯一安全的重建流程
核心是放弃 lock 文件本身，以合并后的 composer.json 为唯一可信源，让 Composer 重新生成。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 先确保
composer.json已 clean merge：运行git merge origin/main或git rebase origin/main，手动解决composer.json中的增删改（如确认"monolog/monolog": "^3.0"是否该保留） - 删掉本地
vendor/和composer.lock（避免残留干扰） - 运行
composer update --no-install：只更新 lock，不重装 vendor；检查输出里是否有意外downloading行（比如guzzlehttp/psr7从2.6.2降级到2.5.0） - 确认无误后
git add composer.lock，提交时附带明确描述，例如：lock: sync monolog ^2→^3 + php 8.3 platform constraint
怎么让 lock 变更只改几行、减少假冲突
Git 标红 lock 不代表依赖变了，大概率是排序或空格差异。关键在统一生成规则：
- 所有成员执行
composer config -g sort-packages true，让packages和packages-dev按字母序固定排列 - 禁用裸
composer update：只允许composer update vendor/package-name --with-dependencies，避免全量重排触发大面积 diff - CI 中加校验步骤：
composer install --dry-run，失败即阻断 PR 合并——说明有人改了composer.json却没提交新 lock - 功能分支完成依赖变更后，尽快合入
main；长期 diverge 会导致composer.json差异过大，重建 lock 时容易漏掉间接依赖变动
最容易被跳过的环境一致性前提
再规范的 lock 流程，也救不了基础环境不一致：如果本地 PHP 是 8.2，而 CI 用 8.4，且 composer.json 里没设 "config": {"platform": {"php": "8.4.0"}}，composer install 会静默选择兼容 8.2 的旧版包（比如装 symfony/console v6.3 而非 v6.4），lock 文件本身没错，但行为已偏移。这问题不会在 Git 冲突里暴露，只能靠统一 platform 配置和 CI 环境镜像来兜底。
