针对Composer库中复杂逻辑导致的堆栈溢出（Stack Overflow）排查-composer-PHP中文网

composer报“recursion limit exceeded”是sat求解器因深度爆炸或闭环循环主动终止，非php栈溢出；区分方法：仅报该错且无重复包名跳转为深度问题，--dry-run -v末行反复跳转或--tree出现vendor/a ← vendor/b ← vendor/a即为闭环实锤。

针对composer库中复杂逻辑导致的堆栈溢出（stack overflow）排查

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：“这个包我已有替代，别再穷举了”