composer 遇到循环依赖会直接中止解析而非报错，典型表现为“root package cannot be installed”且卡在resolving dependencies、cpu拉满、错误中反复出现a→b→a；需用composer depends --tree定位闭环路径，并通过抽离契约包、运行时解耦或降级为可选依赖破环。
Composer 遇到循环依赖不会“解析失败”，它直接判定逻辑不可解并中止——这不是网络或缓存问题，而是依赖图里出现了 A → B → A 这类闭环。必须用 composer depends --tree 定位真实路径，再从结构上破环。
怎么一眼确认是循环依赖，不是版本冲突
看到这些现象，基本可以锁死是循环依赖：
-
Root package cannot be installed且卡在Resolving dependencies超过 30 秒（CPU 拉满，无网络请求） - 错误信息里反复出现
Package a depends on b, which depends on a - 执行
composer update --dry-run -v，末尾几行反复回溯同一组包，比如vendor/a → vendor/b → vendor/a -
composer depends myorg/core --tree输出中出现myorg/core ← myorg/api ← myorg/core（箭头方向是“被谁依赖”，自身出现两次即闭环）
为什么 composer depends --tree 经常查不到包
这个命令有硬性前提，缺一不可：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 项目必须已成功运行过
composer install（保证composer.lock包含完整依赖快照） - 必须加
--tree参数，否则只显示一级依赖，看不到间接环 - 如果报
Package not found，说明该包根本没进composer.lock——先运行composer clear-cache，再删掉vendor/和composer.lock，重试composer update --dry-run看第一步卡在哪
最容易被忽略的隐式循环：autoload + require-dev
很多“循环”根本没写在 require 字段里，而是靠自动加载悄悄打通的：
-
autoload中声明了"psr-4": {"App\": "src/"}，而src/里用了phpunit/phpunit的TestCase -
require-dev包（如phpstan/phpstan）的composer.json里写了"autoload": {"psr-4": {"App\": "../src/"}}，把你的代码路径反向加进了它的加载范围 -
autoload-dev错误地把vendor/下的路径也写进去了——这等于告诉 Composer：“我依赖我自己” - 验证方法：临时注释掉
require-dev下所有非核心工具（phpunit、infection、phpstan），再试composer update；如果恢复成功，问题就在这里
真正有效的破环方式只有三种，没有“跳过”选项
所有靠谱解法都指向一个目标：让依赖方向变成单向。
-
抽离契约包：把共用的接口、DTO、异常类拎出来建新包（如
myorg/contracts），它的composer.json中"require": {}应为空；myorg/core和myorg/api都只require "myorg/contracts": "^1.0" -
运行时解耦：
A不再new B()或use BClass，而是定义LoggerInterface（放契约包），B实现它，A通过容器获取实例；此时A的composer.json里必须删掉对B的require -
降级为可选依赖：
B只在A的测试中用？移到require-dev；是增强功能（如导出 Excel）？改用suggest字段提示用户手动安装
临时删 composer.lock、加 --ignore-platform-reqs 或手动改 vendor/，只会掩盖问题——下次 update 依然崩。真正的难点从来不在命令怎么敲，而在判断哪个类该放进契约包、哪个依赖该从 require 移到 suggest，这需要你打开每个包的 src/ 和 tests/ 目录，一行行看实际调用关系。
