composer install卡在“resolving dependencies”是在本地运行sat求解器暴力穷举所有满足约束的版本组合，包括php版本、扩展、conflict规则及间接依赖区间，并非网络问题；镜像对解析无加速作用，仅影响下载。
Composer install卡在“Resolving dependencies”到底在干啥
这不是网络慢，是 SAT 求解器在本地暴力穷举所有满足约束的版本组合——包括 php 版本、ext-curl 等平台扩展、conflict 规则、以及每个包的 require 间接依赖区间。中文环境下尤其容易因 "platform": {"php": "8.2"} 与本地 PHP 7.4 不匹配，导致求解器反复尝试不兼容版本后回溯失败。
怎么测出解析阶段的真实耗时
别用 time composer install，它混入了下载和文件写入时间。真正要测解析性能，得隔离这一步：
- 先清掉干扰：
rm -rf vendor composer.lock && composer clear-cache - 禁用所有非必要环节：
COMPOSER_MEMORY_LIMIT=-1 php -d xdebug.mode=off composer install --no-dev --dry-run -vvv 2>&1 | grep -E "^(Trying|Checking|Skipping)" | tail -n 50 - 观察最后 50 行日志里
Checking的包名和版本刷屏节奏：如果doctrine/orm[2.15.0]→[2.14.0]→[2.13.0]连续降级，说明它正陷入冲突回溯，不是卡，是无解
镜像对解析速度有没有影响
没有。镜像只加速 packages.json 和 dist 包下载，不影响 SAT 求解。但中文用户常被误导：换镜像后解析更慢，其实是镜像元数据延迟（如阿里云同步滞后 3 小时），导致 Resolver 拿到过期的包版本约束，多走无效路径。验证方法：curl -s https://mirrors.aliyun.com/composer/packages.json | jq '.metadata.lastModified' 对比 packagist.org 时间戳。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
哪些配置会指数级拖慢解析
以下三项在中文项目中高频触发长回溯：
-
"require": {"monolog/monolog": "^2.0 || ^3.0"}：模糊约束让 Resolver 必须同时考虑两个大版本分支的全部依赖图 -
"repositories": [{"type": "path", "url": "./packages/*"}]：通配扫描触发几十次Reading composer.json文件 I/O，CPU 耗尽后 Solver 只能降速 -
"config": {"platform": {"php": "8.3"}}且本地是 PHP 8.1：Resolver 假装运行在 8.3 下选包，结果所有候选都因ext-gd版本不匹配被Skipped due to conflict
最隐蔽的坑是 composer.json 里写了 "packagist.org": false 却没配好镜像 URL——Resolver 会 fallback 到官方源做探测性请求，但国内 DNS 解析 packagist.org 经常超时，表面看是“解析慢”，实际是卡在 TCP 握手。
