必须先确认composer版本是否≥2.2：≥2.2测/packs/packages.json，≤2.1测/packages.json；用curl -w "%{time_starttransfer}"实测ttfb，带user-agent头，设--max-time 5和--retry 2，测后清dns及composer缓存并验证配置生效。
测速前先确认 Composer 版本和镜像路径是否匹配
Composer 2.2+ 默认走 /packs/ 路径（Packagist Mirror 协议），低于该版本仍用 /packages.json 和 /dist/。脚本若统一测 https://mirrors.aliyun.com/composer/packs/packages.json，而用户是 2.1 版本，测速结果完全不反映真实行为。
检查方式：composer --version；若低于 2.2，必须改测旧路径，且要确认镜像是否还支持——例如清华源已停用旧路径，测了也白测。
- Composer ≥ 2.2：测
/packs/packages.json或/packs/ - Composer ≤ 2.1：测
/packages.json（别测首页，会 301 重定向拉长耗时） - 路径错误会导致
404或000，误判为“不可用”
用 curl -w 实测 TTFB，别信 ping 或 time 包裹
ping 测的是 ICMP 延迟，跟 HTTPS 握手、TLS 协商、服务端响应完全无关；time curl 包含 shell 启动开销，不准。真正关键的是 time_starttransfer（TTFB），即服务端开始返回第一个字节的时间。
正确命令示例：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
curl -s -o /dev/null -f \
-H "User-Agent: Composer/2.9.6" \
-w "TTFB: %{time_starttransfer}s, Total: %{time_total}s\n" \
https://mirrors.aliyun.com/composer/packages.json
- 必须带
-H "User-Agent: Composer/2.x"，否则腾讯云等镜像可能返回403 -
%{time_starttransfer}> 1.5s 就已拖慢整个composer update - 别加
--no-keepalive或自定义--dns-servers，否则脱离真实环境
避免脚本卡死：超时与重试必须显式设置
国内部分镜像节点偶发 TLS 握手慢或 DNS 解析失败，curl 默认无超时，脚本可能挂住几分钟。这不是“慢”，是失控。
必须组合使用：
-
--max-time 5：总耗时上限 5 秒 -
--retry 2：单次失败自动重试 2 次，防网络抖动误判 - 禁用并发测速（如后台
&），VPS 出向连接数限制会导致结果失真 - 别用
timeout curl套壳——它无法捕获curl内部的连接阶段耗时
测完不清理缓存，等于白测
测速结果只反映当前瞬时状态，但 Composer 本地缓存（尤其是 ~/.composer/cache/ 和 DNS 缓存）会让后续操作继续走旧逻辑，导致“明明换源了还是慢”。
- 清 Composer 缓存：
composer clear-cache - 清系统 DNS 缓存：
sudo systemd-resolve --flush-caches（systemd）或sudo dscacheutil -flushcache（macOS） - 验证是否生效：
composer config -g repo.packagist.url，输出应为新地址，不是空或https://packagist.org - 项目级配置会覆盖全局，进项目目录后运行
composer config repos.packagist.url确认实际生效源
