composer卡在resolving dependencies是sat求解器暴力穷举版本组合所致，非网络或磁盘问题；可通过composer install -vvv观察日志停驻点、--profile查看耗时占比，并用replace/conflict剪枝、why-not定位阻断链来优化。
Composer 依赖层级过深，根本不是“目录嵌套太多”导致的慢，而是 SAT 求解器在本地暴力穷举版本组合——树越深、约束越松，搜索空间爆炸式增长，Resolving dependencies 阶段卡住几十秒甚至几分钟，是 CPU 在算，不是网络在等。
怎么确认是依赖解析卡住，而不是网络或磁盘问题
运行 composer install -vvv，观察日志停在哪一步：
- 如果长时间卡在
Resolving dependencies后无后续（没报错、没发起 HTTP 请求），就是 SAT 求解器正在回溯，99% 是依赖结构问题 - 如果卡在
Downloading packages或反复出现Reading composer.json，才需要查镜像源、SSH 认证或缓存 - 加
--profile能直接看到耗时分布：composer install --profile，重点关注Resolving dependencies占比是否超 80%
哪些 composer.json 写法会让依赖树失控
不是所有 ^ 都安全，松约束 + 多层传递 = 解析风暴。真正危险的是：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
"monolog/monolog": "^1.0"—— 等价于允许1.0.0到1.999.999，求解器要试几百个版本 -
"phpunit/phpunit": "^9.0 || ^10.0"在require-dev里 —— 强制开启双主版本搜索分支 -
"psr/log": "*"或"php": ">=7.4"—— 完全放弃剪枝依据，求解器失去提前终止条件 -
"some/package": "dev-main"—— 绕过稳定性判断，让 SAT 求解器无法预估兼容边界
不删包、不降级，怎么快速收口依赖树
核心思路是“提前告诉 Composer 哪些组合不可能存在”，跳过无效路径，而不是等它算完再失败：
- 用
replace封死冲突包：比如确认项目只用psr/logv3，就在根composer.json加"replace": {"psr/log": "3.0.0"}，求解器立刻忽略所有 v1/v2 尝试 - 用
conflict屏蔽已知死路："conflict": {"symfony/console": "=10.0"}，避免浪费时间在明确不兼容的版本上 - 查枢纽包再定点干预：运行
composer depends --tree --max-depth=2 monolog/monolog，找出被 ≥5 个顶层包同时拉入的包，它们就是冲突高发点 - 升级时别
composer update全量重算，改用composer update guzzlehttp/guzzle --with-dependencies，只重解目标链
扁平化不是万能解药，这些坑容易被忽略
Composer 把所有包装到 vendor/ 一级，是为了解决同名包版本冲突，但实际效果取决于你如何用它：
-
composer show --tree显示的是逻辑依赖链，不是文件结构——vendor/下永远没有嵌套，但树深仍决定求解复杂度 - 两个不同包名但功能重叠（如
monolog/monolog和symfony/debug）不会被扁平化合并，运行时可能因类加载顺序出问题 -
autoload冲突藏得最深：两个包都映射App\到不同路径，composer install不报错，但运行时类重复定义或找不到类 - CI 中没清缓存就切镜像源，
composer config -g repos.packagist改了也白改——必须跟composer clear-cache才生效
