压测显示 QPS 600、TP99 80 毫秒，看起来很轻。抓包发现每个请求前都有一次 POST /login，token 接口占了总请求数的一半，下单接口实际只跑了 300。乍看像缓存或者权限的锅，追下去往往不是。
jmeter -n -t plan.jmx -Jthreads=500 -Jduration=300 cat result.jtl | awk -F, '$3=="/api/login"' | wc -l
追下去是这么回事：脚本把登录放在每个线程组的循环里，没有用 setUp 线程组只跑一次。token 也没有提取成变量，后续请求带的还是空值，服务端每次都走完整鉴权。压测数字里一半是登录的性能。
「登录态复用」这类改动最怕改一半，回滚脚本先准备好，再动生产。一次只改一处，改完立刻验证，几个改动叠在一起，出问题就说不清是谁导致的。
先做最小复现，能稳定跑出来的问题，排查成本会低一个数量级。
具体做法是，登录放到 setUp 线程组 每个线程只执行一次；用 JSON 提取器把 token 存成变量 后续请求引用；确认下单请求的响应码是 200 而不是 401；单独压登录接口 把它的容量也记下来。
验收就看一点，登录请求只占总请求的 0.2%，下单接口 QPS 与报告一致。