必须用composer update --lock重建，因其是带content-hash校验的依赖快照，手动删标记、调缩进或改顺序会破坏哈希致install失败或静默装错包。
composer.lock 冲突不能手动修，必须用 composer update --lock 重建——它不是配置文件，是带哈希校验的依赖快照，任何文本编辑都会破坏 content-hash 导致 composer install 失败或静默装错包。
为什么手动删冲突标记、调缩进、拼 packages 必然出错
Git 合并留下的 标记本身就会让 PHP 的 <code>json_decode() 报 JSON decode error: Syntax error；即使你手删干净，以下改动仍会触发校验失败：
-
packages数组顺序错乱 →content-hash不匹配 →Package xyz has a mismatched hash - 空行、缩进、字段顺序变动 → JSON 结构合法但语义失效 →
Invalid argument supplied for foreach()（解析跳过关键段） - 保留一方
platform字段（如"php": "8.1"vs"php": "8.2"）→ CI 构建时类找不到，本地却能跑通
冲突发生时只运行 composer update --lock
这条命令不读旧 composer.lock，只基于当前 composer.json 和已安装的 vendor/（如有）生成全新合法快照。它不升级包、不改 vendor/，只重算哈希与结构。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 先确保
composer.json已无冲突：可用git checkout --theirs composer.json或手动整合 - 删掉当前冲突的
composer.lock（或先mv composer.lock composer.lock.bak） - 运行
composer update --lock→ 正常输出应为Lock file operations: 0 installs, 0 updates, 0 removals - 若输出中出现大量
Updating xxx，说明composer.json还没拉齐，需先git pull origin main并重试
怎么让 composer.lock 冲突变少而不是难解
高频“假冲突”往往源于格式扰动而非真实依赖差异。预防比修复更关键：
- 在
composer.json中加"config": { "sort-packages": true }，强制packages数组按字母序排列，消除因安装顺序不同引发的冲突 - 所有依赖变更必须先改
composer.json，立即执行composer update --lock，然后一起提交 —— 禁止只提json不提lock - CI 脚本里加校验：
composer validate --strict && composer install --dry-run，失败即阻断，不给非法lock上线机会
真正麻烦的从来不是冲突本身，而是有人在 composer.json 里写了互斥约束（比如同时 require symfony/console ^5.4 和 ^6.3），这时 composer update --lock 也会报错，得先用 composer why-not symfony/console:6.3 定位源头。
