Composer递归依赖分深度爆炸和闭环循环两类：前者仅报“Recursion limit exceeded(200)”且无包名路径；后者必现嵌套自身依赖或dry-run日志中包名反复跳转，需用composer depends --tree在已install项目中定位并解耦autoload或抽离契约包。
Composer 遇到递归依赖不是“配置没调好”，而是它在约束求解过程中撞上了逻辑死结——要么是深度爆炸（Recursion limit exceeded (200)），要么是闭环循环（Package a depends on b, which depends on a）。这两种情况表现相似（卡在 Resolving dependencies、CPU 拉满、无网络请求），但根因和解法完全不同，混用方案只会浪费时间。
怎么一眼区分是深度问题还是循环问题
别靠猜，看三处输出：
- 报错信息里有没有嵌套指向自身的描述？例如
myorg/core→myorg/api→myorg/core或depends on itself—— 这是循环 - 执行
composer update --dry-run -v，最后 5 行是否反复出现同一组包来回跳转？比如vendor/a→vendor/b→vendor/a—— 循环实锤 - 只有一行
Recursion limit exceeded (200)，且日志里看不到具体包名，也没有重复路径？那就是深度阈值先被触发，大概率是require-dev里混了多个dev-main包，或本地path仓库反向依赖父项目
composer depends --tree 查不出闭环？先确认两个硬前提
composer depends --tree 是目前唯一能定位真实闭环的命令，但它极度依赖环境状态：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（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，得先清理：删掉vendor/和composer.lock，再跑composer clear-cache，然后重试composer update --dry-run - 查的时候别乱选包，优先查你项目里高频出现的枢纽包，比如
psr/log、symfony/console或你自己的核心包名
require-dev + autoload 是最隐蔽的循环来源
你没在 require 里写互相依赖，但 Composer 照样报错——八成是 require-dev 包通过自动加载“悄悄加载了你的代码”，而你的代码又用了它的类，形成运行时闭环：
- 检查所有
require-dev包的composer.json，搜"../src"、"../../"、"tests/"这类路径——它们把你的源码目录加进了自己的autoload - 临时注释掉非核心
require-dev条目，尤其是phpunit/phpunit、infection/infection、phpstan/phpstan这类喜欢跨项目 autoload 的工具 - 确认你自己的
autoload-dev没把vendor/下的路径写进去——这等于告诉 Composer：“我依赖我自己” - 这种隐式循环不会出现在
composer show --tree里，只能靠人工排查 autoload 配置
真正有效的破环方式只有三种，没有“绕过”选项
所有靠谱方案都指向一个目标：让依赖方向变成单向。别碰 --ignore-platform-reqs、--force 或 replace 伪装版本——这些只会让 autoload 更混乱，问题延后爆发：
-
抽离公共契约：把双方共用的接口、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的测试中用，移到require-dev；如果是增强功能（如导出 Excel），改用suggest字段提示用户手动安装
最容易被忽略的是：隐式循环往往不体现在 composer.json 的 require 字段里，而藏在 autoload 路径和 require-dev 的加载行为中——不查这个，光调参数毫无意义。
