Composer遇到循环依赖直接报错退出，不尝试降级或跳过；通过SAT求解器检测A→B→A类闭环，卡在Resolving dependencies超30秒、CPU拉满、报Root package cannot be installed即为实锤，需用composer depends --tree定位并以抽离契约包、运行时解耦或降级为可选依赖三种方式重构解决。
报错卡在 Resolving dependencies 超 30 秒，基本就是循环依赖
Composer 不会尝试“解开”环，它用 SAT 求解器检测到 A → B → A 这类路径就立刻中止。你看到终端 CPU 拉满、无网络请求、几十秒后才抛出模糊错误（如 Root package cannot be installed），不是网络慢或缓存问题，是求解器在闭环里死循环打转。
此时别急着删 composer.lock 或加 --ignore-platform-reqs——这些操作不改变依赖图逻辑，只会掩盖问题。
- 运行
composer update --dry-run -v，盯最后 5 行：如果反复出现vendor/a → vendor/b → vendor/a这种跳转，就是实锤 - 若报
Package not found，说明该包根本没活到构建依赖树那步，先清缓存：composer clear-cache，再删vendor/和composer.lock，重试--dry-run -
composer validate完全无效，它只校验 JSON 格式；composer show默认含require-dev，会干扰判断
用 composer depends --tree 真实定位闭环链路
这是目前唯一能看清谁在拉谁的命令，但有两个硬前提必须满足，否则输出全是假阴性：
- 项目必须已成功执行过
composer install（确保composer.lock有完整快照） - 必须带
--tree参数，否则composer depends myorg/core只显示一级上游，看不到间接环
查可疑包时，直接运行：composer depends myorg/core --tree。如果输出里出现 myorg/core ← myorg/api ← myorg/core，箭头方向是“被谁依赖”，自身出现两次即闭环实锤。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
注意：如果提示 Package not found，不是命令错了，是这个包压根没进 composer.lock，得回上一步清理重试。
require-dev + autoload 是最隐蔽的循环来源
你没在 require 里写互相依赖，但 Composer 依然报错——大概率是 require-dev 包通过自动加载“悄悄加载了你的代码”，而你的代码又用了它的类，形成隐式运行时闭环。
- 检查所有
require-dev包的composer.json，搜"../src"、"../../myproject/src"、"tests/"这类越界路径 - 典型肇事者：
phpunit/phpunit、infection/infection、phpstan/phpstan插件，它们常在自己的autoload里声明"psr-4": {"App\": "../src/"} - 临时注释掉
require-dev下非核心条目（比如测试、静态分析工具），再跑composer update；如果成功，问题就在这里 - 检查你自己的
autoload-dev，确认没把vendor/下的路径写进去——这等于告诉 Composer：“我依赖我自己”
真正有效的破环只有三种，没有“绕过”选项
所有临时手段（删 lock、加 force、改 stability）都只是推迟失败。靠谱解法只指向一个目标：让依赖方向变成单向。
-
抽离契约包：把共用的接口、DTO、异常拎出来建新包（如
myorg/contracts），它的composer.json中"require": {}必须为空；myorg/core和myorg/api都只require "myorg/contracts": "^1.0" -
运行时解耦：A 不再
new B()或use BClass，而是定义ServiceInterface（放契约包），B 实现它，A 通过容器获取实例；此时 A 的composer.json里必须删掉对 B 的require -
降级为可选依赖：如果 B 只在 A 的测试中用，移到
require-dev；如果是增强功能（如导出 Excel），改用suggest字段提示用户手动安装
最容易被忽略的是：dev 分支（如 dev-main）没有语义化版本锚点，解析时取 commit 快照不稳定，极易触发隐式环——生产环境应避免直接 require 开发分支。
