Composer报错“recursion limit exceeded”是其依赖解析器为防止无限递归而触发的保护机制，主因是依赖图中存在循环引用或过深嵌套，常见于require-dev松散约束、path仓库隐式循环及dev分支版本试探。
Composer 报错 “recursion limit exceeded” 是什么问题
这是 Composer 在解析依赖时，发现依赖图中存在过深的嵌套引用（比如 A → B → C → … → A 循环，或单纯层级超过默认阈值），主动中止解析并抛出的错误。它不是 PHP 的致命错误，而是 Composer 自身的保护机制——防止无限递归导致内存耗尽或卡死。
为什么默认 recursion limit 是 200，却还是容易触发
Composer 的 recursion-limit 默认值是 200，但这个数字指的是「依赖解析路径的最大深度」，不是包数量。一旦项目里有多个包互相 require-dev、使用不稳定的分支（如 dev-main）、或存在未收敛的约束（例如 "monolog/monolog": "^3.0 || ^4.0" 配合宽松的其他约束），就极易在解析时反复回溯尝试，快速触达上限。
- require-dev 中的测试工具（如
phpunit/phpunit）常带大量间接依赖，且版本策略松散 - 使用
path类型仓库时，若本地包自身也依赖父项目，会隐式引入循环 - 某些私有包的
composer.json写了"minimum-stability": "dev"却没设"prefer-stable": true，导致解析器陷入版本试探风暴
临时绕过：用 –recursion-limit 调高阈值（慎用）
仅用于诊断或紧急构建，不能解决根本问题。执行命令时加参数即可：
composer install --recursion-limit=500
但要注意：
- 超过 1000 后内存占用会明显上升，CI 环境可能 OOM
- 如果错误变成
Allowed memory size exhausted，说明真有循环依赖，调高 limit 只是掩耳盗铃 - 该参数不影响
composer update的默认行为，后者仍走 200 限制，需显式传入
真正要做的：定位并切断深层依赖链
运行以下命令导出当前依赖树，人工筛查异常长链：
