Composer不处理path依赖循环引用，直接拒绝解析且无明确报错；其本质是SAT求解器在A→path://B→C→A闭环中无限回溯，表现为CPU飙升、卡住或突然退出，需通过--dry-run -v末尾路径重复、depends --tree实锤及检查autoload隐式加载定位。
Composer 不会处理 path 依赖的循环引用——它直接拒绝解析，且不报明确错误，只卡住或静默失败。 这是因为 path 仓库本身不参与 SAT 求解器的约束传播，但一旦被纳入依赖图（比如 A → path://B → C → A），整个闭环就落在求解器里，触发无限回溯。你看到的“没反应”“CPU 占满”“突然退出”，就是它在环里死循环了。
为什么 composer update --dry-run -v 的末尾输出最关键
path 依赖的循环不会在开头报错，而是在求解器反复尝试同一路径链时暴露：vendor/a → ../my-local-b → vendor/c → vendor/a 这类跳转若连续出现 ≥3 次，且中间夹着 ../ 或绝对路径，基本可断定是 path 引入的环。
- 重点盯最后 5–10 行，不是第一行报错
- 若看到
Rejecting ../my-local-b because it requires vendor/a ^2.0，而当前锁的是vendor/a:1.9，说明 path 包把版本约束反向拉进了根项目 - 路径中含
../却又出现在vendor/下游，大概率是 A 通过 path 引用了 B，B 的composer.json又 require 了 A
如何用 composer depends --tree 定位 path 环
composer depends --tree 是唯一能实锤 path 循环的命令，但它有硬前提：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 必须已有有效的
composer.lock（path包已成功解析并写入） - 必须带
--tree参数，否则只显示一级依赖，../my-local-b会被折叠成unknown - 运行
composer depends vendor/a --tree，若输出含vendor/a ← ../my-local-b ← vendor/a，箭头方向表示“被谁依赖”，即闭环成立 - 若报
Package not found，说明该 path 包根本没进 lock——先删vendor/和composer.lock，再跑composer update --dry-run -v看第一步在哪崩
path 仓库的 autoload 是 90% 隐式循环的源头
最常被忽略的“循环”不在 require 字段，而在 autoload 映射里：
- 检查所有 path 包的
composer.json，搜"psr-4"或"classmap"里是否含../、../../src/、tests/—— 比如"App\": "../src/"会让 path 包加载你的根项目代码 - 确认你自己的
autoload-dev没把vendor/下的路径写进去，这等于告诉 Composer：“我依赖我自己” - 临时注释掉 path 包的
autoload段，再试composer update --dry-run -v；如果不再反复跳转，问题就在这 - path 包若启用了
"options": {"symlink": true}，它的 autoload 会实时生效，更容易触发加载时环
真正难排查的不是“哪个包 require 了谁”，而是“哪个 autoload 把谁的类提前拉进了命名空间”。path 依赖让这种隐式耦合变得极隐蔽——它不走 Packagist 的版本校验，却直连文件系统，稍有不慎，加载器就在你没意识到时完成了双向绑定。
