composer 识别出 a→b→a 循环依赖并中止，非解析失败而是架构警告；实锤线索包括报错含嵌套自指、--dry-run -v 反复跳转、install 卡在 resolving dependencies、depends --tree 显示闭环；破环需单向依赖：抽离契约包、运行时解耦、降级为可选依赖。

Composer 出现递归依赖循环，不是它“解析失败”，而是它成功识别出 A → B → A 这种逻辑死结，并立刻中止——它不提供 --force-cycle 或 --skip-dependency-check 这类开关，因为这根本不是安装问题，是架构信号。

怎么确认是循环依赖，不是普通版本冲突

别只盯着报错第一行。真正实锤的线索藏在行为和输出细节里：

• 报错信息含 Package a depends on b, which depends on a 或类似嵌套指向自身描述
• composer update --dry-run -v 最后几行反复出现同一组包来回跳转（如 vendor/a → vendor/b → vendor/a）
• composer install 卡在 Resolving dependencies 超过 30 秒，且无网络日志——SAT 求解器正在死循环里打转，不是慢，是绕不出去
• composer depends --tree vendor/a 输出中出现 vendor/a ← vendor/b ← vendor/a（注意箭头方向是“被谁依赖”）

为什么 composer depends --tree 是唯一靠谱的诊断入口

这个命令直接读取 composer.lock 构建的完整依赖图，但有两个硬前提必须满足：

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

• 必须在已成功执行过 composer install 的项目里运行，否则依赖图不完整
• 必须加 --tree 参数，否则 composer depends vendor/a 只显示一级依赖，根本看不到闭环
• 如果提示 Package not found，说明该包连进 composer.lock 的机会都没有——先删掉 vendor/ 和 composer.lock，再跑 composer update --dry-run -v 观察第一步失败点

require-dev + autoload 是最常被忽略的隐式循环来源

很多“循环”根本不是业务包之间的问题，而是开发依赖通过自动加载反向污染了主依赖链：

• 你在 src/ 里写了 use PHPUnitFrameworkTestCase，而 phpunit/phpunit 的 composer.json 中又写了 "autoload": {"psr-4": {"App\": "../src/"}}，Composer 就会把它当作生产依赖来解析
• 临时注释掉 require-dev 下所有非核心工具（如 phpunit/phpunit、phpstan/phpstan），再试一次 composer update
• 检查所有 require-dev 包的 composer.json，搜 "../src"、"../../myproject/src" 这类路径
• 确认你的 autoload-dev 没把 vendor/ 下的路径写进去——这等于告诉 Composer：“我依赖我自己”

三种真正有效的破环方式，没有第四种

所有靠谱方案都指向一个目标：让依赖方向变成单向。任何 replace 或 provide 伪装兼容，只会让 autoload 错乱，运行时报 Class not found：

• 抽离公共契约：把共用的接口、DTO、异常类拎出来建新包（如 myorg/contracts），它的 composer.json 中 "require": {} 必须为空；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 触发，就不会出现在 composer.json 的 require 字段里——你得翻 src/ 里的 use 语句，再查 dev 包的 autoload 配置，才能定位那个“看不见的依赖”。