resolving dependencies 阶段完全离线，由 composer 本地运行 sat 求解器完成，不依赖任何镜像；镜像仅加速元数据加载和包文件下载。
Resolving dependencies 阶段完全不受中文镜像影响，镜像不参与、不加速、不干预这个过程。
镜像只在两个环节起作用：元数据加载（如 packages.json）、包文件下载（如 .zip 或 .tar.gz）。而 Resolving dependencies 是 Composer 在本地运行 SAT 求解器穷举满足所有约束的版本组合，全程离线，不发任何网络请求。
如果你看到 composer install -vvv 日志里卡在这一行超过 10 秒：
Resolving dependencies through SAT
那说明问题出在本地配置，和镜像无关。此时换阿里云、清华、华为镜像，不会让这一步变快一毫秒。
为什么“Resolving dependencies”慢和镜像无关
这个阶段本质是约束求解问题，耗时取决于：
-
composer.json中 PHP 版本写得太宽，比如"php": "^7.4 || ^8.0 || ^8.1 || ^8.2"，会让求解器尝试数百种 PHP + 包版本组合 - 存在
"minimum-stability": "dev"，强制拉取dev-分支，候选版本数指数级膨胀 -
composer.lock被删或未提交，导致install实际退化为update，触发全量重解析 - 项目
repositories字段指向了响应超时的私有源，Composer 会逐个等待 timeout 后才 fallback，拖慢整体流程
镜像配置写错，反而让你误判瓶颈
90% 的“换镜像没用”其实是配置失败，但 Composer 不报错，静默 fallback 回官方源。常见硬伤包括：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 键名写成
repos.packagist（多一个s），正确只能是repo.packagist - URL 缺少末尾斜杠：
https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌ - 漏掉
composer类型参数：命令必须是composer config -g repo.packagist composer https://...，不能省略中间的composer - 没加
-g参数，结果只改了当前目录的composer.json，换项目就失效
验证是否生效，只看这一条命令输出：
composer config -g repo.packagist
必须返回完整 JSON，形如 {"type": "composer", "url": "https://mirrors.tuna.tsinghua.edu.cn/composer/"}。空、null、或仍是 https://repo.packagist.org，说明根本没配进去。
真正能提速依赖解析的实操动作
想让 Resolving dependencies 快起来，得动本地约束和环境：
- 收紧 PHP 版本约束：把
"php": "^8.0 || ^8.1 || ^8.2"改成明确的"php": "^8.1" - 禁用 Xdebug：
php -d zend_extension= -d xdebug.mode=off composer install，Xdebug 会让求解器慢 3–5 倍 - 删掉
"minimum-stability": "dev"，换成"prefer-stable": true - 执行
composer clear-cache，避免损坏缓存干扰解析路径 - 运行
composer validate --strict，确认composer.json和composer.lock语义合法
复杂点在于：这些调整往往要配合团队协作和 CI 流水线权限一起改——比如宝塔部署默认以 www 用户运行，root 下配的全局镜像对它无效；require-dev 里一堆未锁定的工具包，删了怕测试跑不了，不删又拖慢解析。这类权衡没法靠换镜像绕过去。
