Composer卡在“Resolving dependencies”是SAT求解器暴力回溯版本组合所致，非网络问题；应通过composer why-not定位冲突、--no-dev缩小范围、删require-dev或调整模糊约束来解决。
为什么 composer install 卡在“Resolving dependencies”不动？
大概率不是网络慢，而是 Composer 正在暴力回溯尝试所有可能的版本组合——这通常发生在存在隐式循环依赖或约束过紧时。它不会报错，只是一直“解析中”，CPU 占用高，几小时都出不来结果。
关键判断方式：composer install -vvv 看最后几行是否反复出现类似 Trying: vendor/package:A, then vendor/package:B, then vendor/package:A again... 的循环尝试痕迹；或者卡在 Resolving dependencies through SAT 阶段超过 5 分钟。
- 优先检查
composer.json中所有"require"和"require-dev"是否含模糊约束（如"^1.0 || ^2.0"或"dev-main"），这些会极大增加 SAT 求解空间 - 临时删掉
"require-dev"再试一次，能快速验证是否由开发依赖引发 - 运行
composer prohibits --tree vendor/package-name可定位某个包被哪些依赖间接拉入，辅助识别隐式路径
如何用 composer why-not 定位真实冲突点？
composer why-not 不是“猜哪里错了”，而是给出当前锁文件（composer.lock）下，**为什么某个指定版本无法被安装**的完整约束链。它比 composer update --dry-run 更精准，尤其适合已知目标版本但装不上时。
例如你明确想装 monolog/monolog:^3.0，但失败了：
composer why-not monolog/monolog:3.0.0
输出会逐层列出：A 包要求 psr/log:^1.0 → B 包要求 psr/log:^2.0 → C 包（你自己的）又硬锁了 psr/log:1.1.4 → 最终导致 monolog:^3.0 所需的 psr/log:^3.0 不可满足。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 必须确保
composer.lock存在且最新，否则结果不反映真实状态 - 如果提示
Root package requires ... but it is not present，说明该包根本没出现在当前依赖树里，得先composer require或检查拼写 - 对 dev 分支或私有包，加上
--ignore-platform-reqs可绕过 PHP 版本等平台限制干扰，聚焦纯依赖逻辑
循环依赖的真实表现：不是 A→B→A，而是 A→B→C→D→A
Composer 允许直接的 A→B 和 B→A（会报错），但真正难排查的是跨 3–4 层的隐式闭环。典型场景是：组件库 A 引用了工具库 B，B 为了测试又 require-dev 了 A 的某个命令行工具子包 C，而 C 又依赖了 A 的核心接口抽象 D —— 表面看毫无关联，实际构成环。
这类问题 composer validate 检不出，composer show 也看不出闭环。有效手段只有：
- 用
composer depends --tree vendor/package-name对疑似中心包（如工具类、基础抽象）做反向依赖扫描，观察是否有“自己依赖自己”的路径 - 临时注释掉
"require-dev"下所有非必要包（尤其是带bin或scripts的），再composer update --lock看是否恢复 - 检查
autoload-dev是否意外把 src 目录下的类暴露给了测试依赖，造成隐式耦合
升级到 Composer 2.5+ 后仍卡住？可能是 SAT 求解器被误导
Composer 2.5 引入了更激进的启发式剪枝，但某些特殊约束组合（比如大量 "conflict" 规则 + "provide" 声明 + "replaces"）会让求解器误判可行解空间，陷入无效搜索。
此时不要急着降级，先试试这几个开关：
- 加
--no-suggest关闭建议包加载，排除因 suggest 引入的额外约束 - 加
--prefer-lowest强制从最低兼容版本开始尝试，有时能绕过高版本间的死锁 - 手动编辑
composer.lock，删掉"packages-dev"下所有非必需的开发依赖条目，再composer update --lock
最麻烦的情况是私有仓库返回的 composer.json 缺少 version 字段或含非法语义化版本（如 v1.2.3-rc1 而非 1.2.3-rc1），会导致 SAT 把不同 commit 当作同一版本反复尝试——这种必须修正源仓库元数据。
