循环依赖实锤表现为composer卡在resolving dependencies、cpu拉满、无网络请求；用composer update --dry-run -v观察路径重复，或composer depends --tree定位闭环链路，再检查autoload/require-dev隐式循环。
报错卡在 Resolving dependencies 就是循环依赖实锤
Composer 不会报“检测到循环依赖”，它直接卡住、CPU 拉满、无网络请求——这是 SAT 求解器在死循环回溯。别等它自己退出，立刻执行 composer update --dry-run -v，重点看最后几行是否反复出现同一路径，比如：vendor/a → vendor/b → vendor/a。出现两次即闭环确认。
注意：composer show --tree 默认包含 require-dev，容易干扰判断；composer validate 对依赖逻辑完全无效，别用它诊断。
用 composer depends --tree 定位真实闭环链路
这个命令是唯一能看清间接依赖的入口，但有两个硬前提：
- 项目必须已成功运行过
composer install（保证composer.lock有完整快照） - 必须加
--tree参数，否则只显示一级依赖，根本看不到环
运行 composer depends vendor/a --tree，如果输出中出现 vendor/a ← vendor/b ← vendor/a，箭头方向是“被谁依赖”，自身出现两次就是闭环。如果提示 Package not found，说明该包没进 composer.lock，先删 vendor/ 和 composer.lock，再跑 composer update --dry-run 看第一步失败点。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
检查 autoload 和 autoload-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），然后myorg/core和myorg/api都只require "myorg/contracts": "^1.0"，删掉彼此的require - 运行时解耦：
A不再new B()或use BSomeClass，而是定义interface ServiceInterface（放契约包里），B实现它，A通过容器或工厂获取实例——此时A的composer.json里彻底删掉对B的require - 降级为可选依赖：如果
B只在A的测试里用（比如 Mock 数据），就移到require-dev；如果是增强功能（如导出 Excel），改用suggest字段提示用户手动安装
真正麻烦的是 autoload 越界和 require-dev 反向加载，这类循环不显现在依赖图里，却能让 composer update 卡死。重构前务必先验证是不是这类隐式闭环。
