Composer卡在Resolving dependencies是SAT求解器遍历指数级依赖组合所致，非网络问题；宽泛约束、dev分支、require-dev冲突及platform配置过严会加剧搜索爆炸，导致数分钟卡顿或OOM。
这不是网络卡住，也不是程序挂了，是 Composer 正在做全局逻辑推演——搜索空间爆炸时，它真可能卡住几分钟甚至 OOM。
Resolving dependencies… 卡住的本质是 SAT 求解器在遍历组合空间
Composer 2+ 的 Solver 类不是“试版本”，而是把所有 require、conflict、replace、PHP 平台约束等全部转为逻辑条件，试图找出一组满足全部规则的布尔赋值（每个包选哪个版本）。这个过程是 NP-hard 问题，搜索节点数随依赖数量和可选版本数指数增长。
- 一个宽泛约束如
"monolog/monolog": "*"可能激活 50+ 个历史版本，每个都参与交叉验证 - 多个大生态包（Laravel + Symfony + Doctrine + phpstan）各自带几十个子依赖，组合路径轻易突破千万级
- 若
composer.lock存在且被手动改过composer.json，Solver 会以 lock 为起点做“最小变更”，反而锁死本可解的路径 - CI 环境中
memory_limit设为 128M 或 256M，常在解析 packagist 元数据阶段直接 OOM
为什么局部更新（composer update foo/bar）通常不卡
全局 update 是重建整个依赖图；而指定包更新是复用 composer.lock 中其余包的已验证版本，只对 foo/bar 及其直系依赖重跑求解——相当于把迷宫压缩成一条走廊。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
composer update --with-dependencies foo/bar会扩展到 foo/bar 的 require 链，但依然远小于--with-all-dependencies - 若你发现
composer update laravel/framework成功，但composer update卡住，说明冲突来自其他未显式指定的间接依赖（比如某个 dev 工具强制拉低了phpunit版本） - 加
-v可看到最后尝试的候选链：Resolving dependencies... → monolog/monolog:2.9.0 → guzzlehttp/guzzle:7.8.1 → php:^8.1，这行就是当前 DFS 路径的终点
怎么快速定位并绕过卡点
别等它自己解完。用工具缩小变量空间，比调优内存更有效。
- 先运行
composer update --dry-run -v，观察最后几行拒绝了哪些版本及原因（如skipped: constraint "php": "^8.2" does not allow 8.1.10） - 临时删掉
composer.lock再composer update：清除旧解对搜索路径的隐性限制（仅限开发环境） - 用
composer prohibits vendor/package查谁在阻止某个关键版本，比翻composer show -t快得多 - 检查
config.platform.php是否写死了小版本（如"8.2.0"），应改为"^8.2"给 Solver 更多合法选项
真正难解的从来不是单个冲突，而是多个约束在深层传递依赖中形成的闭环矛盾——比如 A 要 PHP ≥8.2，B 要 A ≥2.0，C 同时 require A 和 B，而 C 自身又声明 conflict 了 A 的所有 ≥2.0 版本。这种结构 Solver 得来回回溯十几层才能确认无解，日志里却只显示一行 “Your requirements could not be resolved”。
