Server Timing 协议无法用于分析 Composer 镜像请求的后端处理耗时，因 Composer 的 HTTP 客户端（cURL/Guzzle）既不发送 Timing-Allow-Origin 请求头，也不解析响应中的 server-timing 字段，完全无感知该协议。
Server Timing 协议无法用于分析 Composer 镜像请求的后端处理耗时——Composer 的 HTTP 客户端（cURL + Guzzle）根本不发送 Timing-Allow-Origin 请求头，也不解析响应头中的 server-timing 字段，整个链路对此协议完全无感知。
Composer 压根不支持 Server Timing 解析
Composer v2.9.6（当前最新稳定版）底层使用 Guzzle 7.x 或原生 cURL 封装，所有 HTTP 请求都只关注状态码、body 和基本 header（如 Content-Type、ETag），对 Server-Timing 这类非标准、非强制的性能诊断 header 完全忽略。即使镜像服务器（如阿里云、腾讯云）在响应中返回了 Server-Timing: cdn;dur=12.4, origin;dur=87.2，Composer 日志里也不会打印、不会记录、更不会暴露给用户。
- 你用
curl -I https://mirrors.aliyun.com/composer/packages.json能看到Server-Timing头，但composer install -vvv的输出里永远不会有这行 -
composer diagnose不检查该协议，composer config --list里也不存在任何相关配置项 - 源码层面：搜索 Composer 主仓库的
src/Composer/Util/HttpDownloader.php和src/Composer/Util/RemoteFilesystem.php，找不到server-timing、timing或dur=等关键词
想看镜像真实耗时，只能靠外部工具实测
要定位是 DNS、TLS、CDN 还是源站慢，必须绕过 Composer 自身逻辑，用命令行工具直接打点：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 测 DNS 解析：
time dig mirrors.aliyun.com @223.5.5.5，若 >300ms，说明本地 DNS 是瓶颈 - 测 TLS 握手+首字节：
curl -o /dev/null -s -w "DNS: %{time_namelookup}, TLS: %{time_appconnect}, TTFB: %{time_starttransfer}\n" https://mirrors.aliyun.com/composer/packages.json - 测完整下载（含解压准备）：
curl -r 0-1048575 -o /dev/null -s -w "Speed: %{speed_download} MB/s\n" https://mirrors.tuna.tsinghua.edu.cn/composer/provider-laravel~framework.json - 确认是否走 HTTP/2（影响并发效率）：
curl -I --http2 https://mirrors.tuna.tsinghua.edu.cn/composer/，返回HTTP/2 200才算真支持
为什么有人误以为 Server Timing 可用
常见混淆点来自浏览器 DevTools —— 当你在浏览器里打开 https://mirrors.aliyun.com/composer/packages.json，Network 面板确实会显示 Server Timing 水平条。但这和 Composer 完全无关，因为：
- 浏览器主动发起请求并解析该 header，Composer CLI 进程不共享浏览器的渲染引擎或 timing API
- Composer 请求是 PHP CLI 进程发出的，没有
PerformanceObserver，也没有navigation.timing上下文 - 即使你用
file_get_contents()手动发请求，PHP 默认也不解析Server-Timing，需自己get_headers()提取再 parse
真正需要后端耗时分析的场景，得在镜像服务侧埋点（比如阿里云运维后台的 Prometheus + Grafana），而不是指望 Composer 客户端反馈。本地能做的只有分层测速：DNS → TCP → TLS → TTFB → 下载吞吐 —— 漏掉任意一层，都会把“镜像慢”错判成“Composer 慢”。
