Composer报“Recursion limit exceeded”是SAT求解器因深度爆炸或闭环循环主动终止，非PHP栈溢出；区分方法：仅报该错且无重复包名跳转为深度问题，--dry-run -v末行反复跳转或--tree出现vendor/a ← vendor/b ← vendor/a即为闭环实锤。
Composer报“Stack overflow”或“Recursion limit exceeded”是求解器卡死，不是PHP栈溢出
Composer本身不会触发PHP层面的Stack overflow错误——它用的是SAT求解器暴力回溯版本组合，所谓“递归”是逻辑依赖图的深度爆炸或闭环，不是函数调用栈真溢出。你看到Recursion limit exceeded (200)，说明求解器在尝试第201层依赖展开时主动放弃，背后要么是深度失控，要么是隐式闭环。
怎么区分深度爆炸和闭环循环？看三处输出
别靠猜，盯住终端最后几行：
- 如果报错只有
Recursion limit exceeded (200)，且composer update --dry-run -v日志里看不到重复包名跳转，大概率是require-dev里混了多个dev-main包，或本地path仓库反向依赖父项目 - 如果
composer depends --tree vendor/package输出出现vendor/a ← vendor/b ← vendor/a这种自指路径，就是闭环铁证——但必须在已有composer.lock的项目里运行才有效 - 执行
composer update --dry-run -v，最后5行反复出现同一组包来回跳转（比如myorg/core → myorg/api → myorg/core），就是闭环实锤
快速定位闭环源头：用composer depends --tree和composer why-not
composer depends --tree只在vendor/和composer.lock完整时才可信；composer why-not则能倒推出阻断链最底层的硬约束：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 先跑
composer depends --tree psr/log（选枢纽包，如symfony/console、monolog/monolog），看是否出现环状缩进 - 再试
composer why-not monolog/monolog:3.0.0（必须带精确版本），输出最后一行是你根composer.json的声明，往上每行都是传递链中卡死的包 - 若
why-not输出里出现your-project dev-main requires ...，说明是你自己写了互斥约束，比如同时require了Laravel 9和Laravel 11的扩展
真正有效的收敛动作：删require-dev、改约束、用replace
绕过求解器暴力回溯，得从约束本身下手：
- 临时删掉
composer.json里的整个"require-dev"段，再composer update --dry-run——很多“栈溢出”其实来自测试工具链的松散约束 - 把
"^1.0 || ^2.0"这类宽泛约束换成"^1.2.0"或"~2.0.0"，前者允许所有2.x，后者只锁2.0.x，后者更容易和其他约束无交集 - 实在无法升级底层包（比如PHP 7.4必须配
guzzlehttp/guzzle旧版），就用"replace": {"guzzlehttp/guzzle": "7.4.*"}告诉Composer：“这个包我已有替代，别再穷举了”
闭环往往藏在autoload里：你没在require写互相依赖，但require-dev包通过自动加载“悄悄加载了你的代码”，而你的代码又用了它的类——这种运行时闭环，composer.json里根本看不出。
