Composer下载忽快忽慢主因是镜像性能未实测、干扰项未关闭；须先用composer config -g repo.packagist确认生效源（必须带/结尾），再用curl测首字节延迟取中位数（超1.5秒排除），启用HTTP/2并设http-max-concurrent-downloads=10，最后执行clear-cache、调高内存、禁用Xdebug。
Composer 中文镜像下载忽快忽慢，不是网络抖动，而是你没测准镜像真实性能，也没关掉干扰项。直接换源不解决问题，得先验证、再调参、最后兜底。
怎么确认当前走的是哪个镜像
执行 composer config -g repo.packagist，输出必须是类似 https://mirrors.aliyun.com/composer/ 这样的完整 URL（结尾带 /）。如果返回空、null、或仍是 https://packagist.org，说明配置根本没生效。
-
repo.packagist不能写成repos.packagist（多一个s就静默忽略） - 项目根目录下
composer.json里若有"repositories"字段，会完全覆盖全局设置，优先级更高 - 用
composer config --list --global和composer config --list对比，才能看出实际生效的是哪一层
为什么测得快，但 composer install 还卡
因为 Composer 不只拉一个文件：它要串行请求 packages.json → 每个 provider-*.json → dist ZIP → 校验 hash。哪怕单个镜像首字节快，中间某一步 TLS 复用失败、DNS 缓存过期、或镜像后端限流，都会卡住整个队列。
- 用
curl -o /dev/null -s -w "%{time_starttransfer}\n" https://mirrors.tuna.tsinghua.edu.cn/composer/packages.json测三次取中位数，超 1.5 秒的镜像别用 - 某些镜像（如旧版 PHPComponer）已停服，URL 重定向跳转吃掉 300ms+，
-vvv日志里看到302 Found就是这个原因 - 阿里云目前仍为 HTTP/1.1，高并发时易排队；清华源支持 HTTP/2，
curl -I --http2 https://mirrors.tuna.tsinghua.edu.cn/composer/返回HTTP/2 200才算真支持
并发下载设多少才不翻车
新版 Composer（2.2+）只认 http-max-concurrent-downloads，parallel-downloads 已弃用且不报错——设了也白设。
- 推荐值是
8～10，别超过12：本地 DNS 并发解析能力、cURL 句柄上限、镜像反爬策略三者共同限制 - 设太高反而更卡，尤其在企业内网或某些 macOS 版本上，容易触发
file_get_contents(): SSL operation failed - 查当前值：
composer config -g http-max-concurrent-downloads；设新值：composer config -g http-max-concurrent-downloads 10
最容易被忽略的三个兜底动作
镜像和并发都配对了还慢？大概率卡在非网络环节。这些动作不花时间，但能立刻排除 70% 的“假慢”。
-
composer clear-cache：缓存里存着旧的packages.json和元数据，Composer 会优先读缓存，哪怕源已改，仍试图从packagist.org拉校验信息 -
COMPOSER_MEMORY_LIMIT=-1 composer install：PHP 默认内存 128M 不够解析复杂依赖图，会导致反复重试 -
php -d xdebug.mode=off $(which composer) install：Xdebug 启用状态下，Resolving dependencies阶段会慢 5–10 倍
真正影响速度的，从来不是“有没有换镜像”，而是“换得对不对”和“其他环节有没有拖后腿”。测、调、清、关——四步做完，再看 -vvv 日志里是不是每条 Downloading 都落在镜像域名上。
