Server-Timing 响应头允许服务端给响应附加具名测量结果，浏览器开发者工具和性能接口随后可以把这些结果与对应资源请求关联起来。当网络瀑布图只能显示等待很久，却无法说明后端是否在查询数据库、渲染页面或执行其他操作时，这类信息很有帮助。但它提供的是服务端选择上报的观测结果，并不是浏览器独立测得这些内部操作的耗时，因此仍然需要理解测量范围和产生位置。
正确的时长语法是 db;dur=42, render;dur=81，建议使用毫秒作为单位。浏览器解析数值，但无法验证发送方实际采用的单位。直接写 db=42，并不是这项协议表达时长的方式。每个指标有名称，也可以带时长和描述参数。生产环境应采用含义稳定的名称，从实际插桩中得到数值。描述可以解释测量对象，但不应包含响应本来不该披露的原始查询、身份编号或内部细节。浏览器能够展示字段，不代表所有调试内容都适合跟随响应对外发送。
让数值对应明确的时间区间 服务端的多个测量值不一定能加成浏览器看到的请求总耗时。它们可能覆盖嵌套操作、相互重叠的工作，也可能只覆盖处理路径的一部分。只有数据库时间与渲染时间的定义允许相加时，加总才有意义。网络传输、测量区间之外的排队、缓存和客户端处理，都可能解释两侧数字的差异，并不一定说明某个时钟有错误。应先弄清每个数值从哪里开始、在哪里结束。
这个响应头也不会自动生成分布式链路。它在单个响应上命名测量结果，并没有自动提供父子关系、跨服务传播或采集器存储。可以用它展示少量对请求有帮助的测量，再通过日志或链路关联获取更深的解释。当响应经过缓存和代理时，还应检查最终交付的响应头，确定这些数字由哪个组件产生。读取一个字段与证明当前源站执行了相应工作，是不同层次的证据。
坏掉的样子 跨源资源存在两个容易混淆的权限边界。CORS 允许脚本读取响应，而 Access-Control-Expose-Headers 可以让 response.headers 暴露 Server-Timing 字段。Timing-Allow-Origin 则控制相应的详细资源计时信息是否可见。安全上下文与浏览器隐私规则还可能进一步限制计时暴露。因此，脚本成功读取响应头，并不能证明 PerformanceResourceTiming.serverTiming 数组一定包含同样的数据。排查时需要分别验证，不能只用其中一个接口有值就推断另一项能力已经成立。
另一个错误，是把解析演示当成真实性能测量。服务端发送固定时长，只能证明浏览器怎样解析这个数字，不能说明处理器实际运行了那么久。同样，计时数组为空，也不能证明服务端没有做任何工作。应先核对来源授权与真实线上响应头，再检查测量代码放置的位置。公开名称与说明还要符合接收对象的范围，避免为了排障而把不该公开的后端结构随响应一起暴露出去。
相同的合成 Server-Timing 可作为响应头读取，却不出现在浏览器性能条目中。原文历史 Chrome 152 对照检查两种暴露权限，不是后端性能测量。 快速验证 将代码保存为 server-timing.py，执行 python3 server-timing.py --serve；此前记录使用 Python 3.14.4；本轮没有重跑套接字或浏览器测试。脚本在两个不同的临时端口上启动本机回环 HTTP 服务，因此它们是不同来源，然后输出待打开的页面地址。页面会请求两份资源，把响应头内容与浏览器解析出的性能条目同时显示出来。结束后按控制键加 C 关闭两个服务；不带服务参数执行时，只检查响应头并退出，不会自动运行浏览器。
...
