以前给接口做压测，流程是固定的：打开 JMeter 建线程组，把抓包里的 URL、请求头、请求体挨个抄进去，签名参数还得写脚本——签名一刷新就变，脚本改了又改，一轮配下来半小时起步。后来换了个路子：从抓包记录直接开压，请求是现成的，签名是"活"的，想测什么当场就能跑。
这篇把这条路走一遍：从抓起一条请求到读懂压测报告，顺带讲清楚一个不少人混着看的问题——恒定 QPS 和并发，压的根本不是同一件事。
先分清：两种模式压的不是同一个问题
- 恒定速率（QPS）：按设定的每秒请求数均匀发压，回答"这个接口在 X QPS 下的真实延迟是多少"。它用的是更严谨的延迟统计口径——高负载下 p99 这类尾延迟依然真实，不会虚低。
- 并发：固定并发数背靠背连发，回答"极限能打出多少吞吐"。
一个回答"扛不扛得住目标流量"，一个回答"天花板在哪"。拿并发的吞吐数字去回答"生产环境 QPS 上去了延迟怎么样"，量出来的东西对不上问题。
下面按操作顺序走一遍，两种模式在哪一步选、结果怎么看，都标在对应步骤里。
第一步：把要压的请求弄进来
在 TraceEagle 里，抓包列表里任意一条请求右键「压测此请求」——方法、地址、请求头、请求体自动带入，缺失的协议自动补全，点开就能开始。这是和"另开一个压测工具"最大的差别：不用先在别处抓、再手动把参数搬过去。
想压不在抓包记录里的目标，也可以从工具箱打开「压测」面板手动填。它是浮窗形式，同时开几个窗口跑几套独立压测都行，互不干扰——多接口并行测试用得上。
第二步：选模式、设压力参数
| 你想知道 | 选哪个模式 | 关键参数 |
|---|---|---|
| 接口在 X QPS 下的真实延迟（含 p99） | 恒定速率（QPS） | 速率 1–100000 req/s |
| 极限吞吐能到多少 | 并发 | 并发 / 连接数 1–2000 |
| 压多久 | 两种模式都要设 | 持续时长 1–3600 秒 |
几个细节：时长按秒数跑，不是"发满 N 个请求就停"——测延迟分布时这个口径更合理；HTTPS 目标会自动尝试 HTTP/2，连接自动复用（keep-alive），测出来的数字更接近真实客户端形态。
跑起来发现数字不对，先查这两类：RPS 上不去，恒定速率模式看速率是不是设低了，并发模式看并发数是不是太小；状态码一片 4xx / 5xx 但接口本身没问题，去高级项里开"跟随重定向"，自签证书的目标开"跳过 TLS 校验"。
第三步：带签名的接口，在这步过坎
这是抓包路线和传统压测工具差别最大的地方。JMeter 压一个签名接口，签名算法得在脚本里重写一遍，服务端改一次算法、脚本就废；而请求是从真实流量里抓来的，签名逻辑本来就对——要做的只是让它"活着"。
请求编辑支持环境变量与动态值：UUID、时间戳、随机数、Base64、MD5 / SHA、HMAC 签名、URL 编码。把签名里的时间戳、随机串换成动态值，请求发出前自动重算——压一小时也不会因为"签名过期"开始报错。会话重放同样吃这套配置，成批重放带签名的私有接口不用手动算。
第四步：读结果下结论
压起来之后，实时面板给这几组数：
- 吞吐：大号实时 RPS + 吞吐折线
- 计数：已发送 / 成功 / 错误 / 已用时
- 延迟分位：p50 / p90 / p95 / p99 / p99.9 / 最大
- 状态码分布：2xx / 3xx / 4xx / 5xx / 错误 分类占比
判断的基准线：恒定 QPS 模式下盯"目标 QPS 下 p99 有没有劣化"；并发模式下找"吞吐不再上升、错误率开始抬头"的拐点，那个点就是实际容量。
分位怎么挑着看也有讲究：p99 是"最慢的那 1% 请求"，用户抱怨的"偶尔卡一下"基本都出在这一段；p99.9 更极端，长尾敏感的场景（支付、下单这类）才需要盯——而且样本要够，只跑十几秒的压测，p99.9 的读数参考价值有限。随时可停，关掉窗口在途压测自动停。
顺带说：成批重放是另一半
压测针对单条请求；另一类需求是"一串请求按原顺序再跑一遍"——多步流程的复现、批量回归、把线上抓到的一段请求切到测试环境重放。
用法：在列表里勾选多条，右键「重放选中的请求」，顺序就是执行顺序；可以设循环次数（整串跑 N 遍）、请求间隔（还原真实节奏），选个环境就能把整串请求切到测试环境。跑完逐条列方法、URL、状态码、延迟，外带成功 / 失败计数和总耗时。回归验证里这个模式顺手：一次改动影响一串接口，跑一遍看哪些状态码变了；延迟列还能留下当基线，改动前后各跑一遍，逐条对比就知道哪条变慢了。
和传统压测工具怎么分工
不否定传统工具：JMeter 适合复杂编排和分布式发压，ab、wrk 命令行打吞吐也利落——它们的共同点是"从零搭请求"，目标越复杂，配置成本越高。
抓包这条路省的是"重建请求"这件事：请求从真实流量来，连同正确的头序和签名，压测与调试共用同一份记录。团队里的实际用法是组合的——日常压测从抓包记录直接开，需要成套场景编排的性能基线测试，把请求从 TraceEagle 导出成 cURL 再搬进专业压测工具，两边各干各擅长的。
接口压测按这个顺序走：抓到请求右键开压，恒定 QPS 问"目标流量下的延迟"、并发问"极限吞吐"，签名接口把动态值配好，拿分位和错误率下结论。串行流程要复现，换会话重放；多个接口并行，多开几个压测窗口。
