composer卡在“resolving dependencies”是本地sat求解器暴力回溯版本冲突所致，非网络问题；镜像仅加速元数据下载，对solver阶段无效，应通过composer why-not定位冲突、--no-dev缩小范围或调整模糊约束来解决。
composer require 卡住，90% 是没切对镜像，不是网络差 —— 切完阿里云或腾讯云镜像后，composer require 通常 1–3 秒完成。
为什么 composer require 会卡在 “Resolving dependencies…”
这不是下载慢，而是 Composer 在本地做依赖图求解（Solver 阶段），纯 CPU 运算，跟镜像无关。但如果你看到卡在 “Loading repository” 或 “Downloading packages.json”，那才是镜像没生效。
- 镜像只加速元数据（
packages.json）拉取，不加速 Solver -
composer require默认会触发全量依赖分析，尤其当composer.json里有"minimum-stability": "dev"或大量"dev-*"版本约束时，Solver 会扫描所有分支，耗时飙升 - 如果
composer.lock已存在且含旧元数据，require可能绕过镜像直接查本地 lock 文件，导致“看似没加速”
composer config -g repo.packagist 必须写对的三个硬伤点
配错就静默回退官方源，不报错、不提示，你根本不知道失败了。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
repo.packagist不能写成repos.packagist（多一个 s）、packagist（漏 repo. 前缀）或mirror（Composer 不识别） - 中间的
composer是 type 值，必须显式写出，不能省略或替换成https等字符串 - URL 必须是 HTTPS 且末尾带
/：例如https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌（少斜杠会 404）
验证镜像是否真生效的三步法
别信感觉，用命令确认：
- 运行
composer config -g repo.packagist，输出必须是完整 JSON 对象：{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}；空、null、报错或只返回 URL 字符串，说明没写进去 - 执行
composer require monolog/monolog -vvv 2>&1 | grep "Loading repository"，日志里应出现你配置的镜像域名，而非packagist.org - 若仍慢，检查
composer.json是否含"minimum-stability": "dev"或未锁定版本的dev-main，这些会让 Solver 放弃镜像缓存，直连 GitHub 分支
composer require 加速的边界在哪
镜像只管元数据下载，其他环节它不管：
- 不加速
Resolving dependencies…—— 这是 PHP 进程在本地穷举版本组合，和网络无关 - 不加速 ZIP 包解压（尤其 Windows + WSL 权限异常时卡在
Extracting archive…） - 不加速
post-autoload-dump或post-root-package-install脚本执行 - 不加速
vendor/autoload.php生成，这个步骤在require后自动触发，但属于文件 IO，非网络瓶颈
真正卡在 Resolving dependencies… 超过 10 秒，就得看 PHP 版本约束、dev 包数量、本地内存是否够用 —— 镜像再快也救不了 Solver。
