composer diag 仅检测配置、证书和网络可达性，不测真实延迟；应使用带 Composer 请求头的 curl 测 TTFB，配合 --resolve 绕过 DNS/SNI 问题，并用 time_starttransfer 排序对比镜像源。
用 composer diag 查看基础连通性但不测延迟
composer diag 会检查 Composer 配置、CA 证书、网络可达性（比如能否访问 packagist.org），但它**不发起真实包元数据请求**，也不测量 HTTP 延迟。它只告诉你“理论上可能通”，不能反映镜像源实际响应快慢。
常见误判场景：本地能 ping 通镜像域名，composer diag 显示 OK，但 composer update 卡在 Fetching packages —— 这说明 DNS 解析或 HTTPS 握手没问题，但镜像服务端响应慢或限流了。
手动测镜像源延迟：用 curl -w 模拟 Composer 的实际请求头
Composer 默认从镜像源获取 packages.json（如 https://mirrors.aliyun.com/composer/packs/packages.json），这个请求带 User-Agent: Composer/2.x 和 Accept: application/json。直接 curl https://mirrors.aliyun.com/composer/packs/packages.json 可能被镜像拒绝或返回缓存页，必须复现真实行为：
- 加
-H "User-Agent: Composer/2.5.0"（版本号可查composer --version） - 加
-H "Accept: application/json" - 用
-w "\nTTFB: %{time_starttransfer}s, Total: %{time_total}s\n"输出首字节时间和总耗时 - 加
-s -o /dev/null -f静默下载、丢弃响应体、失败时不输出错误页
完整命令示例：
curl -s -o /dev/null -f \
-H "User-Agent: Composer/2.5.8" \
-H "Accept: application/json" \
-w "\nTTFB: %{time_starttransfer}s, Total: %{time_total}s\n" \
https://mirrors.aliyun.com/composer/packs/packages.json
注意：部分镜像（如腾讯云）要求 HTTPS SNI 匹配，若提示 SSL 错误，需加 --resolve 强制指定 IP（见下一条）。
绕过 DNS 或验证 SNI：用 --resolve 直连 IP 并指定 Host
有些镜像源做了基于 Host 头或 SNI 的路由，DNS 解析到的 IP 可能和实际服务 IP 不一致（比如 CDN 节点）。此时 curl 直接连域名会失败或跳转，必须显式绑定：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 先用
dig +short mirrors.tencentyun.com查 IP（如119.29.29.29） - 再用
--resolve mirrors.tencentyun.com:443:119.29.29.29强制该域名走该 IP - 同时保留
-H "Host: mirrors.tencentyun.com"，否则服务端可能返回 404
示例：
curl -s -o /dev/null -f \
--resolve mirrors.tencentyun.com:443:119.29.29.29 \
-H "Host: mirrors.tencentyun.com" \
-H "User-Agent: Composer/2.5.8" \
-H "Accept: application/json" \
-w "\nTTFB: %{time_starttransfer}s, Total: %{time_total}s\n" \
https://mirrors.tencentyun.com/packs/packages.json
这步常被忽略——很多“测出来延迟低”的结果，其实是 curl 被重定向到了非镜像的上游源，数据无效。
批量对比多个镜像：写个简单 shell 循环跑 curl 并排序
别靠肉眼记时间。把常用镜像地址写进数组，循环执行上述 curl 命令，提取 time_starttransfer 后用 sort -n 排序：
for url in \
"https://mirrors.aliyun.com/composer/packs/packages.json" \
"https://packagist.phpcomposer.com/packs/packages.json" \
"https://mirrors.tencentyun.com/composer/packs/packages.json"; do
echo -n "$url | "
curl -s -o /dev/null -f \
-H "User-Agent: Composer/2.5.8" \
-H "Accept: application/json" \
-w "%{time_starttransfer}\n" \
"$url" 2>/dev/null || echo "fail"
done | sort -k3 -n
输出类似：
https://mirrors.aliyun.com/composer/packs/packages.json | 0.124 https://mirrors.tencentyun.com/composer/packs/packages.json | 0.207 https://packagist.phpcomposer.com/packs/packages.json | fail
注意：time_starttransfer 更贴近 Composer 真实体验（建立连接+SSL+发送请求+收到第一个字节），比 time_total 更有参考价值；多次运行取中位数，避免单次抖动干扰。
真实延迟还受本地网络出口、镜像节点负载、是否启用 HTTP/2 影响，单次测试只能作相对参考。最准的方式，还是在空项目里跑一次 composer require monolog/monolog:3.0.0 --no-install，看 Downloading https://... 那行的实际耗时——那才是 Composer 真正卡住的地方。
