Composer国内镜像只代理元数据不托管zip包，配了阿里云或清华镜像后仍卡在Downloading https://codeload.github.com/，根本原因是composer.lock固化旧dist.url，必须删除composer.lock和vendor/后重新install才能生效。
Composer国内镜像只代理元数据，不托管zip包
配了阿里云或清华镜像后 composer install 还卡在 Downloading https://codeload.github.com/，不是镜像没生效，而是你误以为“换源=全链路加速”。国内镜像（如 https://mirrors.aliyun.com/composer/）只提供 packages.json 和版本索引——也就是“哪些包、有哪些版本、依赖谁”，但实际 zip 包仍从 GitHub 原地址下载。它不缓存、不重写、不代理 codeload.github.com 或 api.github.com 的响应。
常见错误现象：
-
composer install -vvv日志里Loading composer repositories飞快，但某一行Downloading https://api.github.com/卡住 30 秒以上 -
composer config -g repo.packagist输出正确，但速度毫无改善 - 删了
vendor/重装，依然走 GitHub 域名
真正起作用的环节只有两个：
- 查包是否存在、有哪些版本（走镜像）
- 解析依赖图时拉取各包的
dist.url字段（这个字段在composer.lock里固化）
composer.lock 是镜像是否生效的最终判决者
composer.lock 文件里每个包的 dist.url 字段决定了实际下载地址。哪怕你刚配好镜像，只要 lock 文件是上次直连 GitHub 生成的，composer install 就会照着旧 URL 去下载——完全无视任何镜像配置。
所以“换源后没提速”的核心原因就一个：composer.lock 没刷新。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 必须删除
composer.lock和vendor/后再执行composer install，否则新镜像对下载路径无效 -
--repository-url=https://mirrors.aliyun.com/composer/对已有composer.lock完全无效，它只影响元数据拉取阶段 - CI 或宝塔部署中，如果
composer.lock提交到了 Git，那每次构建都复用旧路径，镜像形同虚设
全局配置 repo.packagist 的三个硬性条件
这条命令看似简单，但错任意一处都会静默 fallback 到 packagist.org，且不报错：
- 键名必须是
repo.packagist（单数repo，不是repos；不能大小写混写） - 中间的
composer是type值，不可省略（composer config -g repo.packagist composer ...✅） - URL 必须是 HTTPS + 末尾带斜杠：
https://mirrors.aliyun.com/composer/✅，少斜杠会拼出/composerpackages.json导致 404
验证是否写入成功，只看这一行输出：
composer config -g repo.packagist
正确结果要么是 JSON：{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}，要么是纯 URL 字符串。空、null、或仍是 https://packagist.org，说明根本没生效。
并发下载只加速网络等待，不解决 DNS/TLS 卡顿
http-max-concurrent-downloads 是 Composer 2.2+ 唯一有效的并发参数，默认为 6。设成 8～10 有一定收益，但前提是镜像源真能响应。
- 并发只在
composer install阶段生效，composer update因依赖解析强串行，基本不受益 - 如果每个请求都卡在 DNS 解析或 TLS 握手（比如 CI 环境没配
COMPOSER_NO_TLS=1），开 10 个线程只是 10 个超时排队 -
parallel-downloads已废弃，设了也无效 - 并发效果只能通过
composer install -vvv日志观察：多行Downloading https://mirrors.aliyun.com/几乎同时滚动才算真正启用
最常被忽略的一点：镜像只改元数据入口，不改下载路径；而真正拖慢安装的，往往是 GitHub 的 TLS 握手和跨洋路由——这点再高的并发也救不了。
