事情本身不复杂，线索都在日志里。一台 5M 带宽的轻量应用服务器，接口返回 JSON 约八十 KB，压测 QPS 到三百时延迟从二十毫秒跳到两百毫秒，服务端 CPU 只有两成。
第一反应是「压测请求带了 no-cache，CDN 完全没参与分发」，验证下来不成立。
排查方向其实有限，先把可能性排一排。单次响应体太大，带宽先到顶，延迟随 QPS 线性上涨。少数情况下是没开 gzip，文本内容白占了四五倍体积。
另外，带宽是峰值计费，超过阈值被限速到更低档。
第一件事是看压测期间网卡出方向的流量
sar -n DEV 1 10 | grep eth0接着开启 gzip 并确认真的生效
curl -H 'Accept-Encoding: gzip' -I https://www.example.com/api/list精简响应字段只返回需要的列
curl -s https://www.example.com/api/list | wc -c静态与接口分流到 CDN 后复测
wrk -t4 -c200 -d60s --latency https://www.example.com/api/list怎么算真的好了，看的是同一批现象。响应体压到十 KB 以内后，同样的 QPS 下延迟回到三十毫秒，出方向流量降到带宽的六成以下。
这里还有个坑。带宽型瓶颈的典型特征是 CPU 闲、延迟随并发线性涨；先算一遍单请求体积乘 QPS，再决定是加带宽还是减体积。线上能稳定复现的问题都不算难，难的是只在大流量下才出现的那种。