composer.lock中不会出现同一包多个版本，所谓“重复”多是依赖树展开或循环依赖的表象；真正版本冲突仅因lock损坏、手动编辑或危险操作导致。
composer.lock里出现同一包多个版本？先确认是不是真重复
Composer 不会在 composer.lock 中写入同一包的多个版本——它只保留最终解析出的**唯一确定版本**。所谓“重复依赖”，90% 是你用文本编辑器打开 composer.lock 后，看到同一包名在不同嵌套层级反复出现（比如 monolog/monolog 在 root require 和某个 vendor 包的 require 里都出现了），误以为是“重复记录”。这其实是正常依赖树展开结果，不是错误。
真正需要警惕的“重复”现象是：composer show --tree | grep "monolog/monolog" 输出中，同一个包被不同路径引入、且版本号不一致（如 monolog/monolog 2.10.0 和 monolog/monolog 3.5.0 并存）。这种情况只可能发生在 lock 文件损坏、手动编辑过 lock、或用了 --no-update + 手动改 require 的危险操作之后。
用 composer show --tree 检查真实依赖路径是否闭环
“重复”常是循环依赖的表象。比如 myorg/core → myorg/api → myorg/core 这种链路，在 composer show --tree 输出里会表现为 myorg/core 出现 ≥2 次，且父级不同。这不是重复安装，而是 Composer 拒绝解析成功前的残留状态。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 运行
composer show --tree myorg/core，观察输出中是否含myorg/core ← myorg/api ← myorg/core这类箭头回环 - 若输出为空或报
Package not found，说明该包根本没进 lock——先删vendor/和composer.lock，再跑composer update --dry-run -v看第一步失败点 - 别只跑
composer depends myorg/core（无--tree），那只会显示一级上游，完全看不出间接环
检查 require-dev 是否偷偷引入自身
80% 的“重复感”来自 require-dev 里的 autoload 跨目录加载。例如 phpunit/phpunit 的 composer.json 里写了 "autoload": {"psr-4": {"App\": "../src/"}}，就会让它把你的 src/ 当成自己的代码加载——等于让 dev 工具反向依赖了你自己。
- 搜所有
require-dev包的composer.json，重点找../、../../、src/、tests/这类路径 - 检查你自己的
autoload-dev，确认没把vendor/下的路径写进去（比如"Tests\": "vendor/myorg/test-utils/src/"） - 临时注释掉
phpunit/phpunit、infection/infection等喜欢跨目录 autoload 的工具，再试composer update --dry-run -v；如果不再反复跳转，问题就在这
锁文件损坏时的最小干预修复法
真遇到 composer.lock 被手动改坏、导致解析卡死或报错“invalid lock file”，不要直接删 lock 再全量 update——那会丢失生产环境一致性。优先用 Composer 自身机制恢复：
- 运行
composer update --lock：它不改任何包，只校验并重写 lock 文件结构，修复 JSON 格式或字段缺失问题 - 若失败，再试
composer update --dry-run -v，盯住末尾 5 行：反复出现的同一组路径（如vendor/a → vendor/b → vendor/a）就是闭环证据 - 确认闭环后，用
composer depends --tree定位实锤链路，再决定抽离契约包、改为运行时解耦，或降级为可选依赖
最易被忽略的是：循环依赖不会表现为“装了两个版本”，而是根本走不完依赖解析——CPU 持续 95%+、内存每秒涨 50MB+、终端卡住几十秒后突然退出。这时候翻 lock 文件本身没意义，得看 --dry-run -v 的末尾输出和 depends --tree 的实锤链路。
