composer下载卡顿主因是dns解析、tls握手、ttfb及镜像后端排队，而非出口带宽；需验证镜像url格式正确、生效且支持http/2，调优http-max-concurrent-downloads参数，并排查xdebug、内存不足等本地处理瓶颈。
出口带宽延迟不是 Composer 下载卡顿的真实原因——它根本不会被带宽瓶颈卡住，而是卡在 DNS 解析、TLS 握手、首字节响应（TTFB）和镜像源后端排队上。所谓“下载慢”，99% 是请求发不出去或等不到第一个字节，不是后续数据流慢。
确认当前镜像是否真生效且可用
执行 composer config -g repo.packagist，输出必须是完整 HTTPS URL 且以 / 结尾，例如 https://mirrors.aliyun.com/composer/。空、null、或仍含 packagist.org 都说明没生效。
- 键名错写成
repos.packagist（多一个s）会静默忽略 - URL 少末尾
/会导致拼接出错，返回 404 ——https://mirrors.aliyun.com/composer❌，https://mirrors.aliyun.com/composer/✅ - 项目级
composer.json中的"repositories"字段会完全覆盖全局配置，用composer config -l | grep repositories检查是否被劫持 - 加
-vvv运行composer install，搜日志里Downloading行的域名，只有出现mirrors.aliyun.com或mirrors.tuna.tsinghua.edu.cn才算真走镜像
镜像源本身性能不稳怎么办
阿里云目前仍为 HTTP/1.1，高并发时易排队；清华源支持 HTTP/2，更适配现代网络。但不能只看名字，得实测：
- 用
curl -o /dev/null -s -w "%{time_starttransfer}\n" https://mirrors.tuna.tsinghua.edu.cn/composer/packages.json测三次取中位数，超 1.5 秒的镜像别用 - 检查是否重定向：
curl -I --http2 https://mirrors.tuna.tsinghua.edu.cn/composer/返回HTTP/2 200才算真支持 HTTP/2 - 旧镜像如
https://packagist.phpcomposer.com已停服，返回 404；华为源已 302 跳回packagist.org，别再填
并发下载参数设多少才不翻车
parallel-downloads 在 Composer 2.2+ 已被弃用，设了也不生效——这是最常踩的坑。必须用 http-max-concurrent-downloads：
- 查当前值：
composer config -g http-max-concurrent-downloads - 设推荐值：
composer config -g http-max-concurrent-downloads 10 - 别超过 12：企业内网、某些 macOS 版本或 DNS 并发解析弱的环境，设太高反而触发
file_get_contents(): SSL operation failed - 该参数只对
composer install有效，update仍串行解析依赖图，调它没用
真正拖慢的从来不是下载，而是本地处理环节
如果卡在 Resolving dependencies 或 Installing xyz/abc 不动，和镜像、带宽、并发全无关：
-
COMPOSER_MEMORY_LIMIT=-1临时提内存：默认 128M 在复杂依赖下极易 OOM 回退重试 - 禁用 Xdebug：
php -d xdebug.mode=off $(which composer) install，CLI 下 Xdebug 会让解析慢 5–10 倍 - 删干净再重来：
rm -rf vendor/ composer.lock，再跑composer install --no-cache，避免 lock 文件残留已下线包触发降级查找 - 私有包硬编码 GitHub URL（如
"dist": {"url": "https://github.com/..."}）会绕过镜像，只能配github-oauth.github.comToken 或换 Gitee zip 地址
最容易被忽略的是：镜像只加速「下载」，不加速「解析」和「解压校验」。一旦看到 Resolving dependencies 耗时超 90 秒，立刻关 Xdebug、提内存、清锁文件——别再盯着网络参数调了。
