答案是先运行composer config -g repo.packagist确认输出为含正确URL的JSON，再用curl -I -w "%{time_starttransfer}" -m 5 测试镜像/packages.json的首字节响应时间。
怎么确认当前用的是哪个镜像
先跑 composer config -g repo.packagist，输出必须是类似 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"} 这样的 JSON。如果为空、null 或报错，说明根本没生效，测速毫无意义——很多人卡在这一步，却直接去 curl 镜像地址，白忙活。
为什么 composer diagnose 不能测镜像速度
composer diagnose 默认强制访问 https://packagist.org，完全无视你配的任何镜像。它只会告诉你 PHP 版本、OpenSSL、curl 扩展有没有，跟网络连通性无关。如果你看到 curl error 7: Failed to connect to packagist.org，别慌，这不是镜像问题，是它本来就要连官方源。
真实测速必须用 curl -I 测 /packages.json
Composer 启动时第一件事就是 GET 镜像根路径下的 /packages.json，这个请求的首字节时间（time_starttransfer）最能反映实际体验。用法如下：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 用
-I（HEAD 请求），不下载完整文件，避免带宽干扰 - URL 必须带
/packages.json后缀，比如https://mirrors.tuna.tsinghua.edu.cn/composer/packages.json；只测/composer/可能重定向或返回 HTML，结果无效 - 加
-m 5设超时，防止单个镜像卡死拖垮整个脚本 - 取
%{time_starttransfer}而非%{time_total}，前者排除 DNS 解析时间，更贴近 Composer 行为
示例命令：curl -I -o /dev/null -s -w "%{time_starttransfer}\n" -m 5 https://mirrors.aliyun.com/composer/packages.json
一次测不准，得看中位数且避开干扰项
单次结果波动大，建议每镜像跑 3 次取中位数。超过 1.5 秒基本可排除——Composer 是串行读多个 provider 文件的，卡一个就全队列阻塞。
- DNS 缓存要清：Linux 用
systemd-resolve --flush-caches，macOS 用sudo dscacheutil -flushcache - 别信“大家说清华快”：你家宽带走的是移动还是电信？教育网用户用清华源可能直连北京骨干网，但你用的是联通，就绕到广州节点了
- 杀软/防火墙可能拦截 HTTPS 连接，临时关掉再试
- 已停用的镜像（如
phpcomposer.com、laravel-china.com）别测，返回 404 或超时是常态
真正影响速度的从来不是镜像本身，而是你本地网络到那个镜像后端服务器之间那条链路的质量——DNS、TLS 握手、CDN 调度、并发限制，每一环都可能成为瓶颈。测速只是帮你定位哪一环出了问题，不是找“永远最快”的答案。
