用户说卡，不是慢

客服转来一句反馈：页面时快时慢，点一下转好几秒，再点又好了。

这种情况我一开始按「慢」去查，测了三次都挺快，差点回一句「我们这边正常」，那就是把问题推回给用户了。

卡顿的特征是不稳定

先把它当成波动问题，方向就对了，一味加配置通常没有效果。

稳定地慢，说明某个环节一直有固定开销，这种反而好查。

一会儿快一会儿停，说明某个环节在抖动，而平均值恰好会把这种抖动平均掉，看起来还不错。

所以先别问「多慢」，要问「多久卡一次、卡多久、什么时间卡」，这三个问题能把范围缩小很多。

五段里谁在跳

抖动会藏进某一段，逐段看才找得到，凭感觉只会越猜越偏。

DNS：解析一会儿快一会儿慢，通常和缓存过期、递归服务器负载有关，这类抖动很隐蔽。

TCP：建连时间忽长忽短，多半是链路丢包和重传，跨境线路尤其明显。

TLS：握手偶发变长，可能是证书链要额外取一次，或者服务端算力在高峰被占满。

TTFB：忽高忽低最典型，服务端排队、慢查询、锁等待、GC 停顿都会这样。

下载：传输中途掉速，常见于带宽被打满、并发太高，或者中间链路在丢包重传。

用多节点把范围缩下来

范围越小，改起来越省事，也越容易验证有没有效果。

只有一个节点卡，可能是那个节点本身的问题，先别上升到全站。

按运营商分组，某一家普遍卡，问题在互联，这时候找运营商比改代码有用。

用宝塔拨测的网站测速跑多地区多运营商节点，连续几次结果放在一起看，波动落在哪一段、集中在哪些组合，比看单次报告清楚得多。

复测要看间隔

间隔和轮次，决定结论能不能站住，测一轮就下判断太草率。

同一组节点，隔几分钟测一次，连续测三到五轮，条件保持一致。

看最慢节点和最快节点的差距有没有周期性，晚高峰和凌晨各测一轮，差异最容易暴露。

只有复测才能把「偶发」和「持续」分开，这两种的处理成本差很远。

动作顺序

顺序错了，越修越乱，最后连原来的现象都复现不了。

先修波动最明显的那一段，一次只改一处，不然分不清是哪处起效。

改完隔一天再复测，别在同一分钟里连刷，缓存和连接都还没稳定。

卡顿消失不代表永远不出现，把它记进监控、定好阈值，才是真正的收尾。

卡顿这类问题，最怕的不是难，是没耐心连测。

多测几轮，答案往往自己就出来了。

出来了，就别急着结束，记一笔。