composer卡在“resolving dependencies”是sat求解器因约束冲突或搜索空间爆炸而暴力回溯，并非网络问题；应优先用composer why-not定位阻断链、composer depends --tree识别循环依赖、临时移除require-dev缩小范围。

Composer 不会“设置”递归依赖，它只解析你声明的依赖及其传递链；所谓“卡在 resolving dependencies”，本质是 SAT 求解器在爆炸的版本组合空间里反复回溯失败——不是递归太深，而是约束冲突或搜索空间失控。

为什么 composer install 会卡住十几分钟甚至失败

这不是网络慢，也不是 composer 版本旧，是求解器正在穷举满足所有 require、conflict、platform 和 replace 的版本组合。一个包有 40 个可用版本，5 个强依赖就可能产生上百万种初始排列。

• minimum-stability: dev 会让每个包的 dev-main、dev-develop 都进入候选集，搜索空间指数级膨胀
• 国内直连 packagist.org 时，fetch 元数据（packages.json）叠加解析，常卡在 Resolving dependencies through SAT 行不动
• require-dev 里的测试工具（如 infection/infection）若 autoloads 了你的 src/，又反过来被你代码调用，会形成隐式闭环，求解器在 A→B→A 之间无限打转
• 根 composer.json 中写了 "psr/log": "^1.0 || ^2.0 || ^3.0" 这类宽泛约束，等于主动放弃剪枝机会

快速定位阻塞点的三个核心命令

别猜哪一层“递归”深，直接查谁在拖慢或锁死求解：

Discussion Composer

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

下载

• 运行 composer prohibits vendor/package：查哪个包明确用 conflict 或通过 require 锁死了某个版本
• 运行 composer why-not vendor/package:3.0.0：输出具体哪条依赖链拒绝该版本，例如 laravel/framework v10.32.1 requires monolog/monolog ^2.9
• 运行 composer depends --tree vendor/package：看是否出现 vendor/a ← vendor/b ← vendor/a 这种自指路径——这是循环依赖的铁证，且必须在已有 composer.lock 的项目中运行才有效

真正有效的收敛手段：从约束入手，而非绕过

用 replace 或 provide 是权宜之计，但前提是已确认无法升级底层包（比如必须用 PHP 7.4，而新 guzzlehttp/guzzle 要求 8.0+）。它们不解决“能不能装”，而是告诉 composer：“这个包我已有替代实现，别再费劲找兼容版本了”。

• "replace": {"symfony/console": "5.4.*"} —— 彻底覆盖某包，需确保你自己的实现能承载全部接口调用
• "provide": {"psr/log-implementation": "1.0"} —— 更轻量，只声明能力，适合对接口契约明确的场景
• 临时删掉 require-dev 再试一次，很多“递归爆炸”其实来自测试工具链的松散约束
• 加 --no-dev 安装生产环境，或用 composer why-usage guzzlehttp/psr7 查它是否只被测试工具引入；若是，可安全剔除

循环依赖必须从结构打破，没有捷径

Composer 遇到 A → B → A 直接报错退出，不提供 --force 或 --skip-cycle。报错信息里出现 Package a depends on b, which depends on a 就是实锤。

• 最隐蔽的来源是 autoload + require-dev 组合：某测试包把你的 src/ 加进自己的自动加载路径，而你又用了它的基类，运行时闭环就形成了
• 破环只有三种方式：抽离公共契约（建 myorg/contracts 包）、运行时解耦（A 不再 require B，改用 interface + 容器注入）、降级为可选依赖（suggest 替代 require）
• 别试图用 replace 伪装版本兼容——这只会让 autoload 更混乱，且掩盖真实架构问题

复杂点从来不在“递归多深”，而在不同层级对同一包的版本诉求不一致；最容易被忽略的是 require-dev 引入的隐式依赖和 autoload 导致的运行时闭环——它们不会出现在 composer show --tree 里，却能让求解器彻底卡死。