必须实测镜像链路质量，因DNS解析、TLS握手、CDN调度和并发限制差异导致速度波动；推荐用curl测元数据首字节延迟和ZIP吞吐，中位数超1.5秒即排除，并根据网络类型设http-max-concurrent-downloads为6–10。
Composer镜像下载速度在不同网络下波动大，不是镜像“不稳定”，而是你当前网络与镜像后端之间的链路质量差异真实存在——DNS 解析、TLS 握手、CDN 节点亲和性、并发连接策略这几环，任意一环不匹配，就会拖慢整条流水线。
为什么同一镜像在办公室快、在家慢？
根本原因是本地网络出口到镜像服务器的路径不同，关键差异点如下：
- DNS 解析走的是运营商缓存还是污染 DNS：比如某些宽带 ISP 会劫持
mirrors.aliyun.com解析到劣质节点，而企业内网可能已部署可信 DNS（如114.114.114.114） - TLS 协商能力不一致：家庭路由器常禁用 TLS 1.3 或 OCSP Stapling，导致每次握手多耗 200–500ms；办公网络则可能已优化 TLS session 复用
- CDN 节点调度不准：阿里云镜像在北方用户可能被分到广州节点，清华镜像对教育网用户自动切到北京骨干网，但你家宽带没走教育网，就绕行了
- 本地 cURL 并发限制：家用路由器或防火墙默认限制单 IP 每秒新建连接数，
http-max-concurrent-downloads设为 10 可能触发限流，降为 6 反而更稳
怎么实测哪个镜像真适合你当前网络？
别信“大家说清华快”，要跑真实请求。重点测两个阶段：
- 元数据首字节延迟（影响
Resolving dependencies）：curl -o /dev/null -s -w "%{time_starttransfer}\n" https://mirrors.tuna.tsinghua.edu.cn/composer/packages.json - ZIP 包吞吐（影响
Downloading）：curl -r 0-1048575 -o /dev/null -s -w "%{speed_download}\n" https://mirrors.aliyun.com/composer/provider-laravel~framework.json
每条命令跑 3 次取中位数；任一结果超 1.5 秒直接排除——Composer 串行处理每个 provider 文件，卡一个就全队列阻塞。
http-max-concurrent-downloads 设太高反而更慢？
是的。这个值不是“带宽越大越好”，它受三重制约：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 本地 DNS 并发解析能力：设 12 时，若系统
resolv.conf只配了 1 个 nameserver，会排队等解析 - cURL handle 复用失效：高并发下 TLS session 复用率下降，重复握手开销陡增
- 镜像服务反爬策略：华为云/阿里云对单 IP 瞬时连接数有软限制，超限返回
429 Too Many Requests，Composer默认重试 3 次，实际耗时翻倍
实测建议值：8（南方宽带）、6（老旧企业防火墙）、10（教育网或千兆光纤直连）——别统一设 15。
为什么 -vvv 日志里看到下载域名是镜像，但速度还是慢？
因为日志只显示 URL，不反映真实跳转。常见隐形坑：
- 镜像 URL 已停服，但 HTTP 302 重定向到新地址：比如访问
https://packagist.phpcomposer.com会跳转到https://mirrors.tuna.tsinghua.edu.cn/composer/，中间多一次 RTT（+300ms） - 镜像未启用 HTTP/2：用
curl -I --http2 https://mirrors.aliyun.com/composer/测，返回HTTP/1.1就说明不支持多路复用，高并发时包排队明显 - 杀毒软件或上网行为管理拦截 HTTPS 流量，强制解密再加密，TLS 握手时间翻倍，且易丢包
真正卡住的地方，往往藏在三次握手之后、首字节之前——这点容易被忽略，但恰恰是换镜像后仍慢的主因。
