答案是Composer安装慢90%源于镜像配置错误：键名必须为repo.packagist（非repos）、type值必填composer、URL须含末尾/，三者缺一即静默回退至packagist.org；验证需同时满足config输出正确JSON及install -vvv日志显示镜像路径。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
composer 安装慢，90% 的问题不是网络差，而是镜像根本没配对——写错键名、漏掉 composer 类型参数、URL 少了末尾 /，三者任一出错，composer 都会静默 fallback 到 https://packagist.org，且不报错、不提示。
确认当前生效的镜像源是哪一条
很多人以为执行了composer config -g repo.packagist 就配好了，结果输出为空、null 或仍是 https://packagist.org，说明完全没生效。真正起作用的是：
- 输出必须是完整 URL 字符串（如
https://mirrors.aliyun.com/composer/）或标准 JSON 对象（如{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}） - 键名必须是
repo.packagist（不是repos.packagist，多一个s就被忽略） - URL 必须以
https://开头、以/结尾，缺一不可
为什么 composer clear-cache 这一步不能跳过
缓存里存着旧的 packages.json 和 provider 元数据，composer 会优先读本地缓存再校验远程地址——哪怕你已经切了镜像，它仍可能反复尝试从 https://packagist.org 拉取索引，卡在 DNS 解析或 TLS 握手阶段。
- 必须用
composer clear-cache（不是composer cache-clear，后者已废弃） - 执行后应看到两行输出：
Clearing cache (cache-dir):和Clearing cache (cache-vcs): - 临时验证是否绕过缓存：加
--no-cache跑一次composer install -vvv，看日志里请求的是哪个域名
项目级配置比全局更可靠
在宝塔、CI 或多用户环境下，composer config -g 很可能写到了错误用户的家目录（比如 /root/.composer/config.json），而实际运行时是 www 用户，根本读不到。
- 进项目根目录，运行：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（不加-g） - 该命令会自动向
composer.json的repositories数组追加 packagist 条目，不覆盖已有私有源 - 配置随 Git 提交，新人拉完即用；CI 构建时无需额外环境准备
- 若项目已有
"repositories": {}，手动编辑易出错，务必用命令追加
composer install -vvv 日志才是唯一真相
配置写对了、缓存清干净了，不代表真走镜像。最终验证必须看日志：
- 运行
composer install -vvv，滚动到最后几行，找类似：Reading packages.json from cache at /home/user/.composer/cache/repo/https---mirrors-aliyun-com-composer/packages.json - 如果看到的是
https---packagist-org或其他旧域名，说明 fallback 了，当前命令仍在走海外源 - 临时强制指定镜像测试：
composer install -vvv --repository-url=https://mirrors.tuna.tsinghua.edu.cn/composer/
Resolving dependencies 阶段的卡顿——那完全是本地 CPU 和 PHP 环境的事，跟网络无关。 
