用curl测packages.json首字节延迟（TTFB）最准，命令为curl -I -w "%{time_starttransfer}" -m 5 -k https://mirrors.aliyun.com/composer/packages.json，取3次中位数，超1.5秒即排除。
怎么用 curl 测 packages.json 的真实响应时间
测镜像快慢，只看 packages.json 的首字节延迟（TTFB）最准——这是 Composer 每次 install 或 update 开头必发的请求，卡在这里，整个流程就停住。
- 必须用
curl -I（HEAD 请求），不是-s -o /dev/null（GET 下载），避免浪费带宽和受 ZIP 包大小干扰 - 关键指标是
%{time_starttransfer}，它反映服务端返回第一个字节的时间，排除 DNS 和连接建立干扰 - 超时设
-m 5，防止某个镜像卡死拖垮整轮测试 - URL 必须带
/packages.json后缀，例如https://mirrors.aliyun.com/composer/packages.json；只写根路径可能重定向或返回 HTML，测了白测 - 别信一次结果：跑 3 次取中位数，
time_starttransfer超 1.5 秒直接排除——Composer 是串行加载 provider 列表，卡一个就全队列堵死
为什么 composer diagnose 完全不能用来测镜像
composer diagnose 根本不读你配的镜像，它硬编码访问 https://packagist.org，哪怕你已切到清华源，它报的 curl error 7 也只是连不上官方站，和镜像无关。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 它真正能检查的只有三件事：PHP 版本、OpenSSL 是否启用、curl 扩展是否存在——全都不依赖网络
- 如果你看到 “Connection refused” 或 “Failed to connect”，别急着换镜像，先确认
composer config -g repo.packagist输出是不是你预期的 URL - 输出为空？说明根本没配镜像，还在直连海外；输出是
https://packagist.org？那配置压根没生效，得回看键名、type 值、末尾斜杠有没有写错
脚本测速时容易踩的坑
写个 for 循环并发测几个镜像看似简单，但实操里一堆隐形雷。
- DNS 缓存未清：Linux 上
systemd-resolve --flush-caches，macOS 上sudo dscacheutil -flushcache，否则旧解析结果会污染结果 - 用了
%{time_total}：它包含 DNS 解析、TCP 握手、TLS 协商全部时间，而 Composer 实际复用连接，真正瓶颈在服务端响应，所以必须用%{time_starttransfer} - 没加
-k：华为云等部分镜像证书链不全，curl默认校验证书会失败，测速时加-k跳过（仅限测速，非生产） - 并发开太高：一次测 4 个镜像就足够，再多反而触发本地 DNS 或镜像反爬限流，返回 429 或 TLS 握手变慢
- 忘了
composer clear-cache：旧缓存可能让后续install看似快，其实和镜像无关，测速前务必清掉
测完怎么选？别迷信“最快”，要看稳不稳定
阿里云镜像当前同步延迟最短（2–5 分钟），HTTPS 响应一致性最好，适合日常开发；清华源对 IPv6 和教育网更友好，但偶发 403；腾讯云南方节点快，华北用户可能绕行。
- 已停用的镜像（如
phpcomposer.com、laravel-china.org）别测，URL 返回 404 或超时是常态，不是你网络问题 - 测出“阿里云最快”，但
composer install还是慢？大概率是本地杀软拦截 ZIP 下载、磁盘 I/O 瓶颈，或http-max-concurrent-downloads设太高触发镜像限流 - CI/CD 环境建议固定一个源（推荐阿里云），别搞自动测速切换——钩子脚本异常退出会中断构建，且不同 runner 网络环境差异大，测速结果不可复现
time_namelookup、time_appconnect 才能定位真问题。 
