需分环节测真实延迟：curl测packages.json首字节响应（超1.5秒排除）、测provider-*.json下载吞吐，DNS解析须刷新，且composer diagnose不可靠，仅发HEAD不校验响应体。
为什么测速结果不稳定，不能只看 composer update 耗时
Composer 拉包不是单次 HTTP 请求，它分四步串行执行：packages.json → provider-*.json → dist ZIP → 校验哈希。某一步卡住，整条链就堵死。阿里云镜像用 HTTP/1.1，高依赖项目容易排队；腾讯云支持 HTTP/2，连接复用更稳，但教育网 DNS 常指向海外节点，首次请求易超时。杀毒软件（如 Windows 上的腾讯电脑管家）可能静默丢 HTTPS 包，导致 curl 测得快、composer install 却忽快忽慢。
用 curl 分环节测真实延迟，别信 composer diagnose
composer diagnose 只发 HEAD 请求，不校验响应体结构，可能返回 OK 却实际返回 HTML 错误页。真正有效的检测要拆开两步：
- 测元数据首字节延迟：
curl -o /dev/null -s -w "%{time_starttransfer}\n" https://mirrors.cloud.tencent.com/composer/packages.json，重复 3 次取中位数，超 1.5 秒直接排除 - 测 ZIP 下载吞吐：
curl -r 0-1048575 -o /dev/null -s -w "%{speed_download}\n" https://mirrors.aliyun.com/composer/provider-laravel~framework.json，URL 必须带末尾/，否则 302 重定向多耗 300ms+
每次测试前加 getent ahosts mirrors.cloud.tencent.com 确认 DNS 解析没缓存旧 IP，避免误判。
composer config -g repo.packagist 配置不生效的三个硬伤
配置写进去 ≠ 真生效。常见失效原因有三个：
- URL 少了末尾
/：写成https://mirrors.aliyun.com/composer会拼出/composerpackages.json导致 404 - 漏掉
type值：composer config -g repo.packagist composer https://...中的composer是 type，不是注释，不可省 - 被项目级
composer.json覆盖：只要含repositories字段，就会无提示覆盖全局配置，且不报错
验证是否成功：运行 composer config -g repo.packagist，输出必须是完整 JSON：{"type": "composer", "url": "https://mirrors.cloud.tencent.com/composer/"}。空、null 或仍是 https://packagist.org，说明根本没写进去。
换源后仍卡在 “Loading composer repositories”，其实是缓存和锁文件在捣鬼
这不是网络问题，是元数据缓存没刷新或 composer.lock 记录的是旧源地址：
-
composer clear-cache清 ZIP 和 provider 缓存 - 强制刷新元数据：
composer update --refresh（≥2.5）或手动删缓存目录：rm -rf $(composer config --global cache-dir)/repo/https---mirrors-cloud-tencent-com-composer - 删掉旧
composer.lock文件再重装——它记录的是原始源地址，不删就永远走不了新镜像 - 加
-vvv参数看真实请求地址，否则等于“盲装”
最常被忽略的是：企业内网可能拦截 HTTPS 请求，临时调试可试 composer config -g secure-http false，但别留到生产环境。
