Composer卡在Resolving dependencies不是依赖死循环，而是SAT求解器暴力穷举版本组合所致；常见诱因包括宽泛约束（如"^1.0 || ^2.0"）、dev-main引用、require-dev工具链冲突等，此时换镜像、清缓存、调超时均无效。
composer install卡在Resolving dependencies是依赖死循环吗
不是。这一步根本不是网络问题，更不是“死循环”，而是 Composer 在暴力穷举满足所有 require 约束的版本组合——当约束太宽、包太多、或引入了 dev-main 这类不稳定的分支时，求解空间爆炸，耗时可能从几秒拉长到几十分钟甚至卡住不动。
哪些 composer.json 写法会触发求解器卡死
常见高风险写法包括：
-
"^1.0 || ^2.0"这类跨大版本的宽松约束，让求解器必须同时考虑两套不兼容的 API 兼容性 - 显式 require 了
"some/package": "dev-main"或"dev-develop"，这类分支没有固定版本号，Composer 会反复尝试解析最新 commit，极易陷入回溯 - 项目中同时 require 多个强耦合但未声明互斥关系的包（如两个 UI 库都强制要求不同版本的
symfony/event-dispatcher） -
require-dev里混入了生产环境不需要的大体积工具链（如phpstan/phpstan+infection/infection），显著增加约束维度
怎么快速验证并绕过求解阶段卡死
先确认是否真卡在求解环节：运行 composer install -vvv，如果日志停在 Resolving dependencies 且 CPU 占用持续高于 80%，基本可判定是 SAT 求解器瓶颈。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
临时缓解方法：
- 缩小
require范围：注释掉部分非核心依赖，跑一次composer install看是否能过；再逐个放开定位冲突源 - 禁用
require-dev：加--no-dev参数跳过开发依赖解析，大幅降低求解复杂度 - 临时提高内存上限：用
php -d memory_limit=-1 composer install避免因 OOM 中断 - 换用更激进的求解策略（Composer 2.9+）：
composer install --prefer-stable --optimize-autoloader，让求解器优先收敛到稳定版本
为什么清缓存、换镜像对Resolving dependencies完全无效
因为这一步压根不发网络请求——它纯属本地 PHP 计算，只读 composer.lock（如果有）或 vendor/ 缓存中的元数据，然后在内存里做逻辑推演。镜像、DNS、IPv6、http.timeout 全部不参与此阶段。
真正容易被忽略的是：如果你删了 composer.lock 又没指定具体版本，Composer 就得从头开始暴力求解整个依赖图。所以保留一份可用的 lock 文件，比反复调参数更重要。
