当我们谈论「延迟」时，到底在谈什么

每次和产品同学开会，"延迟"这个词至少会出现 8 次。但他说的是"用户感觉到慢"，我说的是"P99 抖动"，DBA 说的是"查询响应时间"，老板说的是"业务转化率掉了"。我们说的根本不是同一个东西。

这件事让我意识到，延迟是一个被滥用的概念。要把它讲清楚，至少要分四层：

• 稳态延迟：系统在正常负载下的延迟分布。
• 尾延迟：高百分位（P99、P99.9）的延迟。
• 抖动：同一请求在不同时刻的延迟差异。
• 感知延迟：用户实际感受到的"快慢"，包含网络、渲染、交互。

稳态延迟不是平均值，是分布

如果只看一个数字，那就看分布。最常见的描述方式是直方图与百分位。但很多团队只看平均延迟，这是错的。延迟从来不是正态分布，它是长尾分布。一个 100ms 的平均延迟，可能意味着 80% 的请求都在 20ms 内完成，但剩下 20% 拖到了 400ms。

平均延迟是一种"统计安慰剂"。它让团队觉得"还行"，但其实用户体验已经很差。

百分位的解读方式

同一份延迟数据，不同百分位讲不同故事：

但百分位本身也有坑：相同的 P99 在不同 QPS 下含义不同。QPS=100 时 P99=500ms 只影响 1 个用户/秒；QPS=10000 时影响 100 个用户/秒。

抖动：被低估的杀手

"延迟 50ms"听起来很好，但如果它在 5ms 与 200ms 之间跳来跳去，体验远比稳定 50ms 差。抖动来源于 GC 停顿、内核调度延迟、网络包重传、缓存未命中的随机 IO。抖动是 P99 与 P50 之间的距离。一个稳态系统，P99 / P50 比值应该小于 3。超过 10 就要警惕。

感知延迟：用户的尺

用户感受到的延迟 = 网络往返 + 服务端处理 + 客户端渲染 + 交互响应。一个 TTFB 50ms 的页面，可能因为阻塞渲染的脚本导致 LCP 1500ms。所以工程师关注的不应只是 server-side latency，而是 RUM 数据里的 LCP/INP。Google 给出的"用户感知阈值"是：< 100ms 感觉"瞬时"，100ms–1s 感觉"流畅但有等待"，1–3s 感觉"慢"，> 3s 感觉"卡"。所以 SLO 设到 P99 < 800ms 不是凭空定的，是和"用户感觉慢的临界点"挂钩的。

延迟数据的工程化呈现

我建议团队把延迟数据做成三视图：分布直方图（看形状，是不是长尾）、时间序列百分位（看趋势，P99 是否在恶化）、热力图（看模式，有没有周期性抖动）。这三张图加起来，比任何一个数字都更能描述"系统到底快不快"。

把"延迟"翻译成"业务语言"

最有用的延迟沟通是把延迟翻译成业务影响。"P99 从 200ms 涨到 600ms"是技术语言；"结算页 1% 的用户多等了 0.4 秒，导致 0.3% 的用户放弃支付"是业务语言。后者能让产品同学立刻理解为什么这件事要做。延迟不是技术指标，是用户体验的工程化翻译。把它讲明白，团队才有共识。