composer install卡在“resolving dependencies”是sat求解器在暴力穷举满足所有约束的版本组合，非网络问题；应通过composer install -vvv观察回溯路径、composer why-not定位冲突、删require-dev或收紧模糊约束来解决。
Composer install 时卡在 “Resolving dependencies” 是什么在干活？
这是 composer install 最常被误认为“卡死”的阶段，实际是依赖解析器（DependencyResolver）正在做 SAT 求解——它不是在下载，而是在穷举满足所有 require、conflict、PHP 版本约束、平台配置（如 ext-curl）的包版本组合。中文环境下尤其容易因镜像源同步延迟、platform 配置与本地环境不一致（比如 composer.json 写了 "php": "^8.1"，但本地是 PHP 8.0），导致求解时间指数级增长甚至超时。
- 用
composer install -v可看到每轮尝试的候选版本回溯路径，关键线索藏在类似Trying: monolog/monolog[2.10.0, ..., 3.0.0]的日志里 - 若日志反复出现
Skipping ... because of conflicts或Could not resolve package，说明约束冲突已无法绕过，不是慢，而是无解 - 中文用户常忽略
platform配置：如果本地 PHP 是 7.4，但composer.json中写了"platform": {"php": "8.2"}，Resolver 会假装运行在 PHP 8.2 下求解，结果选一堆不兼容的包再失败
如何快速定位哪个包触发了无限回溯？
当 composer install -vvv 日志滚动到几百行仍没进展，重点盯住最后连续出现的 Checking... 行——它表示 Resolver 正在为某个包枚举版本。例如：
Checking <code>doctrine/orm</code> for version candidates<br> Checking <code>doctrine/orm[2.15.0]</code><br> Checking <code>doctrine/orm[2.14.0]</code><br> Checking <code>doctrine/orm[2.13.0]</code>
如果这个包下面紧跟着大量 Skipped ... due to conflict with ...，且版本号越刷越旧（从 2.15 → 2.10 → 2.7），基本就是它和另一个包（比如 symfony/console）存在隐式冲突：两者各自要求的间接依赖（如 psr/cache）版本区间无交集。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 临时移除疑似问题包（如
composer remove doctrine/orm），再install看是否秒过，可快速验证 - 用
composer prohibits --tree vendor/package-name查该包为何被拒绝，比读日志更直接 - 注意中文路径或含空格的项目路径可能触发 Composer 内部异常（虽少见），先 cd 到纯英文路径下重试
为什么换国内镜像后反而解析更慢？
镜像只加速下载，不加速解析。但部分镜像（如阿里云、腾讯云）的 packages.json 元数据更新延迟数小时，会导致 Resolver 拿到过期的版本信息（比如某包已删掉 PHP 8.0 不兼容的 v1.2.0，但镜像还挂着），反复尝试无效版本。此时 composer clear-cache + composer config repo.packagist composer https://packagist.org 切回官方源，往往能立刻破局。
- 不要盲目信任“国内加速”等于“全局加速”，解析阶段完全不走镜像
-
composer show --platform输出的 PHP 和扩展版本，必须和本地php -v、php -m严格一致，否则 Resolver 会在错误假设下求解 - 某些企业环境禁用了 TLS 1.3，而 Packagist 新接口强制要求，表现为
Unable to load metadata后无限重试——这不是解析慢，是网络层根本连不上
什么时候该放弃手动调试，直接改约束？
当 composer why-not package/version 显示冲突链超过 4 层，或日志里出现 Too many backtracks（Composer 2.2+ 默认阈值 200 万次），说明问题已超出人工推演能力。这时候硬看日志不如主动收缩范围：
- 把模糊约束如
"^2.0"改成具体版本"2.3.1"，大幅减少搜索空间 - 删掉非必需的
conflict规则（尤其第三方包自带的），它们常和当前生态不匹配 - 对主框架（Laravel/Symfony）用
create-project新建干净项目，再逐个require自己的包，比在老项目里硬解更快
Resolver 没有“心路历程”，只有布尔逻辑和回溯计数器。它不理解你为什么需要这个包，只认得约束是否自洽。最有效的分析，永远是从报错倒推，而不是盯着滚动日志等它“想通”。
