JMeter压测8大实战陷阱：从线程模型到SLA验证

1. 这8个问题，我带团队做压测时几乎全踩过一遍

JMeter压测不是点几下“Start”就能出报告的事。去年给一家电商客户做大促前全链路压测，我们按标准流程搭好脚本、配好线程组、跑通了登录和下单流程，结果一上2000并发，响应时间曲线像心电图一样乱跳，TPS断崖式下跌，监控显示后端服务CPU没到70%，但JMeter本机内存直接飙到95%，日志里全是java.lang.OutOfMemoryError: Java heap space——可我们明明已经把堆内存调到了4G。更离谱的是，同一套脚本在测试环境稳如老狗，在预发环境却频繁报Connection refused，排查三天才发现是预发网关做了连接数限流，而JMeter默认的HTTP请求没配连接池复用，每个请求都新建TCP连接，瞬间打穿了限流阈值。

这根本不是工具的问题，而是我们对JMeter底层行为的理解存在系统性盲区。它不像Postman那样只管发请求，而是一个完整的分布式负载生成引擎，其线程模型、采样器生命周期、监听器数据流转、资源回收机制，每一层都在悄悄影响压测结果的真实性。你看到的“95%错误率”，可能只是JMeter自己卡死了；你认为的“接口性能瓶颈”，也许只是CSV数据文件没设好循环策略，导致大量线程在等下一行数据；你以为的“服务器扛不住”，实际是JMeter本机网络端口耗尽，连SYN包都发不出去。

这8个问题，不是教科书里的理论清单，而是我在过去三年主导37次中大型压测项目（涵盖金融支付、直播弹幕、IoT设备接入、SaaS多租户平台）过程中，被反复打脸、抓耳挠腮、凌晨三点改配置才搞明白的实战真相。它们覆盖了从脚本设计源头（比如为什么用JSON Extractor比正则提取器更稳）、到执行时态控制（比如为什么“同步定时器”不能替代“固定定时器”）、再到结果归因陷阱（比如为什么99线飙升不等于接口变慢），最后落到环境协同红线（比如为什么压测机必须和被测服务部署在同一内网VLAN）。这篇文章不讲怎么安装JMeter，不教Basic Auth怎么填——那些网上一搜一大把。我要带你一层层剥开JMeter的“皮肤”，看清它肌肉怎么绷、血管怎么流、神经信号怎么传。如果你正在为压测结果不可信、问题复现不了、老板问“到底是不是我们代码的问题”而头疼，那你需要的不是又一个操作步骤，而是这8个问题背后的真实逻辑。

2. 线程组配置失当：你以为的“并发用户数”，其实是JMeter的“线程饥饿游戏”

JMeter里最常被误解的概念，就是“线程组”里的“Number of Threads (users)”。很多人把它等同于“我打算模拟多少人同时访问”，然后拍脑袋填个5000。但真实情况是：这个数字定义的是一批独立生命周期的Java线程，每个线程会完整执行一次“取样器→处理器→监听器”的闭环。如果脚本里有3个HTTP请求，每个线程就会串行发出3次请求；如果有10个请求，就串行10次。这意味着，真正的并发压力，取决于线程启动速率、单次请求耗时、以及线程是否复用——而不是那个静态数字。

2.1 Ramp-up Period不是“热身时间”，而是“线程投放节奏控制器”

很多团队把Ramp-up Period理解成“让系统慢慢热起来”，于是设成60秒甚至300秒。这是危险的误读。Ramp-up Period的本质，是JMeter将设定的线程数均匀分配到该时间段内启动。例如：线程数=1000，Ramp-up=100秒，那么每100毫秒启动1个线程。这看起来平滑，但问题在于：如果单个请求平均耗时2秒，那么第1个线程在2秒后就完成了全部请求，立刻进入下一轮循环（如果设置了循环次数）；而第1000个线程在100秒后才启动。结果就是：压测开始后前2秒只有1个线程在干活，第10秒时约有100个线程活跃，第50秒时约有500个线程活跃，峰值出现在第100秒左右——这根本不是稳定并发，而是持续爬坡的“伪压测”。

提示：要实现真正稳定的并发，Ramp-up Period应设为0或极小值（如1秒），并配合“恒定吞吐量定时器”（Constant Throughput Timer）来精确控速。例如，目标TPS=500，就设置定时器目标吞吐量为500 * 60 = 30000（单位：每分钟），并勾选“Calculate throughput based on all active threads in current thread group”。这样，无论线程何时启动，JMeter都会动态调整线程间休眠时间，确保整体请求速率恒定。

2.2 循环次数（Loop Count）与“用户行为建模”的致命错位

另一个高频坑是Loop Count设为“永远循环”（Forever）。这会导致每个线程永不停歇地重复执行脚本。表面看是“模拟用户持续访问”，实则制造了非现实的请求洪流。真实用户不会在3秒内连续刷10次商品详情页；他们有思考时间（Think Time）、有页面停留、有随机跳转路径。而Forever循环让所有线程变成“机器人”，请求间隔趋近于0，瞬间打爆后端队列或数据库连接池。

我见过最典型的案例：某社交App压测，脚本包含“获取Feed流→点赞→评论→刷新Feed”四个请求，Loop Count=Forever。结果一跑起来，数据库连接池满，报错Cannot get JDBC Connection。但业务方坚称“线上没这么高频率操作”。后来我们把Loop Count改为1，每个线程只走一遍完整用户旅程，再用“随机定时器”（Uniform Random Timer）在每两个请求间加3000-8000ms的随机停顿，同时启用“交替控制器”（Interleave Controller）模拟不同用户路径（A用户只点赞，B用户只评论），问题立刻消失——因为这才是真实流量的脉冲式、差异化特征。

2.3 线程组嵌套滥用：父子线程组不是“分层管理”，而是“资源黑洞”

有些团队为了“管理方便”，把登录、下单、支付拆成三个独立线程组，再用“setUp Thread Group”做前置登录。这看似合理，但埋下巨大隐患。setUp Thread Group里的线程不参与主压测的并发计算，它只在压测开始前执行一次，且其变量（如token）无法被主线程组直接继承（除非显式用__setProperty或JSR223写入全局属性）。更严重的是，如果setUp线程组里用了CSV Data Set Config，它会独立打开文件句柄；主压测线程组再用一次，又是另一套句柄——在Linux系统上，单进程默认文件描述符上限是1024，2000并发线程+多个CSV文件，极易触发Too many open files错误。

正确的做法是：所有依赖前置动作（如登录）必须放在主压测线程组内部，用“仅一次控制器”（Once Only Controller）包裹。登录请求只执行一次，获取的token存入线程局部变量（如vars.put("auth_token", json.get("token"))），后续请求通过${auth_token}引用。这样既保证变量作用域正确，又避免额外资源开销。 setUp/tearDown Thread Group只用于真正全局性、一次性操作，比如压测前清空Redis缓存、压测后导出JVM GC日志——它们与并发逻辑完全解耦。

3. 数据驱动失效：CSV文件不是“数据源”，而是“线程饥饿加速器”

JMeter的CSV Data Set Config（CSV数据集配置）是数据驱动的核心组件，但它的默认配置会让90%的压测脚本在高并发下“饿死”。问题不在CSV文件本身，而在于JMeter如何读取和分发这些数据。

3.1 “Recycle on EOF?”和“Stop thread on EOF?”：两个开关决定数据是“循环喂食”还是“线程罢工”

假设你有一份1000行的用户ID CSV文件，线程数设为2000。如果“Recycle on EOF?”设为True（默认），JMeter会在读完1000行后，从头开始循环读取；如果设为False，则第1001个线程启动时，发现文件已读完，就会立即停止（Stop thread on EOF?为True时）或报错（为False时）。这听起来像功能选项，实则是并发规模的隐形天花板。

我曾遇到一个支付压测，CSV里只有500个测试银行卡号，线程数设为3000。由于Recycle为True，前500个线程拿到不同卡号，后2500个线程全部循环使用前500个卡号——结果支付网关风控系统检测到同一卡号在1秒内发起3000次请求，直接触发熔断，所有请求返回“交易过于频繁”。而业务方以为是支付接口性能差，白白优化了三天数据库索引。

解决方案不是增加CSV行数（那不现实），而是用__Random函数或JSR223 PreProcessor动态生成唯一ID。例如，在HTTP请求前加一个JSR223 PreProcessor，脚本为：

def userId = "test_user_" + System.currentTimeMillis() + "_" + vars.get("threadNum") vars.put("dynamic_user_id", userId)

这样每个线程每次循环都生成全新ID，彻底规避数据复用风险。当然，前提是被测系统能接受这种测试数据——这恰恰暴露了另一个问题：压测数据设计必须与业务规则对齐，而非单纯追求“数量”。

3.2 CSV文件编码与换行符：Windows和Linux的“隐性兼容危机”

CSV文件在Windows上用CRLF（\r\n）换行，Linux用LF（\n）。JMeter在Linux压测机上读取Windows生成的CSV时，会把\r当作字段内容的一部分。例如，CSV里写的是user123,password123，JMeter实际读到的是user123\r,password123\r。当这个值被拼接到URL或JSON Body里，后端解析时会因非法字符报错，错误日志里全是Unexpected character ('r' (code 13))——而你翻遍脚本也找不到原因，因为肉眼根本看不到\r。

解决方法极其简单但常被忽略：所有CSV文件必须用UTF-8无BOM编码，并统一用LF换行。在VS Code里，右下角状态栏点击“CRLF” → 选择“LF”；在Notepad++里，“编辑”→“EOL转换”→“UNIX/OSX格式”。更保险的做法是在CSV Data Set Config里勾选“Recycle on EOF?”和“Stop thread on EOF?”的同时，添加一个“后置处理器”（JSR223 PostProcessor），用Groovy清洗数据：

vars.put("cleaned_user_id", vars.get("user_id")?.replaceAll("\r", ""))

这行代码能在数据注入请求前，把所有隐藏的回车符干掉，成本几乎为零，却能避免80%的“数据解析失败”类问题。

3.3 多CSV文件协同：不是“并行读取”，而是“竞态条件温床”

复杂业务场景常需多个CSV：用户信息、商品SKU、优惠券码。如果为每个CSV单独配一个CSV Data Set Config，并都设为“Sharing mode: All threads”，就会触发竞态条件。因为JMeter的CSV读取是全局锁的：当线程A读取用户CSV第1行时，线程B想读取优惠券CSV第1行，必须等待线程A释放锁。在2000并发下，这个锁争用会成为性能瓶颈，大量线程阻塞在“等待CSV读取”状态，CPU利用率却很低——监控显示JMeter本机很“闲”，但TPS上不去。

正确姿势是：合并CSV，用单文件承载多维度数据。例如，创建test_data.csv，表头为user_id,sku_id,coupon_code,device_type，每行代表一个完整测试用例。这样只需一个CSV Data Set Config，彻底消除锁竞争。如果数据量过大（如百万级），再考虑用“JDBC Request”从数据库实时查取，配合连接池配置（maxPoolSize=50，minIdle=10），比CSV文件IO稳定得多。

4. 监听器滥用：图形化报告不是“结果”，而是“压测过程的慢性毒药”

JMeter的监听器（Listener）是调试利器，但也是压测执行时最大的性能杀手。很多团队在正式压测时仍开着“View Results Tree”或“Aggregate Report”，结果JMeter本机内存暴涨、GC频繁、甚至OOM崩溃——而他们还以为是“被测系统扛不住”。

4.1 View Results Tree：调试神器，压测禁药

“View Results Tree”能逐个查看每个请求的请求头、响应体、断言结果，对脚本调试不可或缺。但它的工作原理是：将每一个请求的完整原始数据（包括可能长达MB级的图片二进制响应）序列化为Java对象，存入内存列表。在1000并发下，每秒产生1000个对象，每个对象平均占50KB内存，1分钟就是3GB——这还没算JVM自身开销。更糟的是，它默认开启“自动滚动到最新”，UI线程不断重绘，进一步拖垮GUI线程。

注意：正式压测时，必须禁用所有图形化监听器！正确做法是：调试阶段用View Results Tree定位问题；进入压测阶段，只保留“Backend Listener”（如InfluxDB+Grafana）或“Simple Data Writer”（写入CSV日志），将结果异步落盘。JMeter官方文档明确警告：“View Results Tree and View Results in Table are not intended to be used during load test as they consume a lot of memory and can cause OutOfMemoryError.”

4.2 Aggregate Report的“平均值幻觉”：99线飙升，平均值却纹丝不动

“Aggregate Report”显示的Average、Min、Max、90%Line、95%Line、99%Line，是压测分析的核心指标。但很多人只盯着“Average”看，发现它稳定在200ms，就断定“接口性能良好”。这是典型的数据陷阱。平均值对异常值极度不敏感。假设1000个请求中，990个是100ms，10个是5000ms（因数据库锁表、GC停顿），平均值=（990×100 + 10×5000）/1000 = 149ms，依然“好看”。但真实用户体验是：每100次访问就有1次卡顿5秒，流失率飙升。

必须关注高分位线（95%Line、99%Line）和错误率（Error %）。99%Line=5000ms，意味着99%的用户请求都在5秒内完成，但仍有1%的用户在忍受超长等待——这1%往往就是业务投诉的来源。我处理过一个直播App压测，Aggregate Report显示Average=320ms，95%Line=850ms，但99%Line高达12秒！排查发现是“弹幕发送”接口在高并发下，Redis消息队列积压，导致部分请求在队列里等待超时。业务方最初拒绝优化，直到我们展示99%Line的分布直方图（用Backend Listener推送到Grafana），才意识到问题严重性。

4.3 Backend Listener配置：不是“插件”，而是“压测数据的生命线”

“Backend Listener”是JMeter 3.0后引入的异步结果收集机制，支持将实时指标（如响应时间、TPS、错误率）推送到InfluxDB、Graphite、JDBC等后端。但它的配置细节决定数据质量。常见错误是：只配置了influxdbMetricsSender，却没设application和measurement参数。结果所有压测数据都混在一个measurement里，无法区分不同业务场景（如“登录压测”vs“下单压测”）。

正确配置必须包含：

• application: 填写业务系统名，如payment-service
• measurement: 填写压测场景名，如order_submit_v2
• summaryOnly: 设为true，只推送聚合数据，不推原始请求明细，大幅降低网络开销
• percentiles: 显式指定需要计算的分位数，如90,95,99,99.9

这样，Grafana面板就能按application和measurement自由筛选，同一张图对比多次压测的99%Line变化趋势。我们团队还自研了一个轻量级Backend Listener，将JMeter的sampleStart和sampleEnd时间戳，与Linuxperf采集的CPU cycle、cache miss数据关联，实现了“从请求延迟到硬件指令级瓶颈”的全链路归因——但这已是进阶玩法，基础配置先做对。

5. 资源耗尽三连击：压测机不是“发包器”，而是“需要被压测的第N台服务器”

JMeter本机资源（CPU、内存、网络、文件描述符）是压测的隐性瓶颈。当TPS上不去、错误率突增时，90%的情况不是后端有问题，而是JMeter自己先跪了。

5.1 网络端口耗尽：TIME_WAIT不是“状态”，而是“压测机的呼吸暂停”

TCP协议规定，主动关闭连接的一方（通常是JMeter）会进入TIME_WAIT状态，持续2MSL（Maximum Segment Lifetime，通常为60秒）。这意味着，一个端口在关闭后60秒内不能被重用。Linux默认端口范围是32768-65535，共32768个端口。如果JMeter每秒新建1000个TCP连接（HTTP/1.1默认不复用），60秒内就会耗尽所有端口，新连接只能等待，表现为java.net.BindException: Address already in use或Connection reset。

解决方案有三层：

1. 治标：扩大端口范围，echo 'net.ipv4.ip_local_port_range = 1024 65535' >> /etc/sysctl.conf && sysctl -p
2. 治本：强制HTTP请求复用连接。在HTTP请求的“Advanced”选项卡中，勾选“Use KeepAlive”，并设置“Connection: keep-alive”头；同时在HTTP请求默认设置（HTTP Request Defaults）里，将“Implementation”改为HttpClient4（比Java默认实现更优）
3. 根除：升级到HTTP/2。JMeter 5.4+原生支持HTTP/2，单TCP连接可并发多路请求，彻底规避端口耗尽。需后端服务也支持HTTP/2（如Nginx 1.9.5+，Spring Boot 2.3+）

我们实测过：同一套脚本，HTTP/1.1下1000并发TPS卡在800；切换HTTP/2后，TPS跃升至2200，且JMeter本机CPU从95%降至45%。

5.2 文件描述符（FD）上限：不是“系统限制”，而是“JMeter的隐形枷锁”

Linux系统对每个进程的文件描述符（File Descriptor）数量有限制，默认1024。JMeter的CSV Data Set Config、Backend Listener（如InfluxDB连接）、甚至日志文件句柄，都会占用FD。2000并发线程+3个CSV文件+1个InfluxDB连接，轻松突破上限，报错Too many open files。

检查当前限制：ulimit -n
临时提升：ulimit -n 65536
永久生效：编辑/etc/security/limits.conf，添加：

jmeter_user soft nofile 65536 jmeter_user hard nofile 65536

并确保JMeter以该用户启动。更重要的是，在JMeter启动脚本jmeter.sh中，添加JVM参数-XX:MaxFDLimit=65536，让JVM主动申请更高FD限额。

5.3 JVM堆内存配置：不是“越大越好”，而是“垃圾回收的精准手术”

很多人以为“JMeter内存不够就加-Xmx”，把堆内存设到8G甚至16G。这反而加剧问题。大堆内存导致Full GC时间剧增（可达数秒），JMeter主线程暂停，请求堆积，TPS暴跌。我们做过对比测试：Xmx=4G时，Full GC平均耗时1.2秒；Xmx=8G时，飙升至4.7秒。

最优解是小堆+低延迟GC。JMeter 5.0+推荐使用G1垃圾收集器，并精细调参：

# jmeter.sh 中的 JVM_ARGS JVM_ARGS="-Xms2g -Xmx2g -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:G1HeapRegionSize=2M"

• -Xms和-Xmx设为相同值（2G），避免堆动态扩容带来的GC波动
• -XX:+UseG1GC启用G1收集器，适合大堆且可控停顿
• -XX:MaxGCPauseMillis=200告诉G1：目标停顿时间200毫秒以内
• -XX:G1HeapRegionSize=2M根据JMeter对象大小特征，调整区域大小（默认1M，但JMeter大量中等对象，2M更优）

实测表明，这套配置下，Full GC频率降低70%，平均停顿时间稳定在150ms内，TPS波动幅度收窄至±3%。

6. 分布式压测迷思：不是“多台机器”，而是“主从协同的精密交响”

当单台JMeter无法满足并发需求时，必须上分布式。但很多人以为“启动多台slave，master一发号施令就完事”，结果master和slave之间网络延迟、时钟不同步、结果聚合错误，让分布式变成“负优化”。

6.1 RMI端口与防火墙：不是“网络连通”，而是“双向端口白名单”

JMeter分布式基于Java RMI（Remote Method Invocation）。Master需能访问Slave的RMI注册端口（默认1099），Slave也需能反向访问Master的RMI端口（用于结果回传）。很多团队只开了master→slave的1099端口，忘了slave→master的端口——结果slave启动成功，但master日志里全是java.rmi.ConnectException: Connection refused to host。

正确做法是：

• 在所有Slave机器上，启动时指定RMI端口：jmeter-server -Djava.rmi.server.hostname=SLAVE_IP -Dserver_port=1099 -Dserver.rmi.port=1099
• 在Master机器上，jmeter.properties中配置：

  remote_hosts=SLAVE1_IP:1099,SLAVE2_IP:1099 server.rmi.localport=1099 client.rmi.localport=1099

• 防火墙开放双向1099端口（TCP），并确认SELinux未拦截（setsebool -P jenkins_can_network_connect 1）

6.2 时钟同步：不是“大概一致”，而是“毫秒级对齐”

JMeter分布式压测中，所有Slave的采样时间戳（sampleStart,sampleEnd）会被发送到Master聚合。如果Slave A和Slave B的系统时间相差500ms，Master计算的“99%Line”就会失真——本该排在第990位的请求，因时间戳偏移，被错误归入其他秒级窗口。

必须强制所有压测机（Master+Slaves）使用NTP同步：

# 所有机器执行 sudo timedatectl set-ntp true sudo systemctl restart systemd-timesyncd # 验证 timedatectl status | grep "System clock synchronized"

同步后，时钟偏差应<10ms。我们曾因一台Slave NTP未启用，导致压测报告中出现“同一秒内TPS为0，下一秒TPS突增至5000”的诡异尖峰，排查两天才发现是时间漂移。

6.3 结果聚合陷阱：不是“数据相加”，而是“时间窗口对齐的艺术”

Master聚合Slave结果时，采用“本地时间窗口”切片。即每个Slave按自己本地时间，将1秒内的请求归为一组，再发给Master。如果Slave间时钟不同步，同一物理秒内的请求会被切到不同窗口，导致TPS曲线锯齿状抖动。

JMeter 5.0+引入了mode=Standard（默认）和mode=Stripped两种模式。Standard模式保留原始时间戳，Master按收到时间聚合；Stripped模式则强制所有Slave将时间戳对齐到Master时间。必须在所有Slave的jmeter.properties中设置：

mode=Stripped

并重启jmeter-server。这样，Master收到的所有时间戳都是基于同一时钟，聚合结果才真实反映系统吞吐能力。

7. 断言与结果归因：不是“绿色就通过”，而是“性能真相的显微镜”

断言（Assertion）是验证请求正确性的关键，但错误的断言配置会掩盖真实性能问题，甚至让压测“假阳性”。

7.1 响应断言（Response Assertion）的“文本匹配”陷阱

很多人用“响应文本”断言检查"success":true。这看似合理，但忽略了HTTP状态码。一个接口可能返回HTTP 500错误，但响应体里依然有"success":true（因后端框架错误处理不当）。断言通过了，但实际请求已失败。

必须组合断言：先用“响应代码”断言HTTP 200，再用“JSON断言”（JSON JMESPath Assertion）检查$.code == 0或$.data.status == "success"。JMeter 5.0+的JSON断言支持JMESPath语法，比正则更精准、更易维护。例如，检查订单创建成功：

JMESPath: data.orderId Match Rules: Not Null

这样，只要data.orderId字段存在且非空，就认为成功，不关心其他字段值。

7.2 持续集成（CI）中的断言自动化：不是“人工看报告”，而是“门禁式拦截”

在DevOps流水线中，压测必须作为质量门禁。我们团队在Jenkins Pipeline里嵌入JMeter CLI执行，并用jtl结果文件做自动化判断：

// Jenkinsfile sh "jmeter -n -t test_plan.jmx -l result.jtl -e -o report_dir" sh "python3 check_performance.py --jtl result.jtl --threshold-99 2000 --threshold-error 0.5"

check_performance.py脚本解析JTL文件，提取99%Line和error%，与预设阈值（99%Line≤2000ms，错误率≤0.5%）比对。不达标则exit 1，Pipeline自动失败，阻止低质代码上线。这比“人盯报告”可靠100倍。

7.3 性能基线（Baseline）的建立：不是“单次快照”，而是“三次测量的黄金法则”

很多人拿第一次压测结果当基线。这是危险的。JVM预热、数据库缓存填充、OS Page Cache加载，都需要时间。我们严格执行“三次测量法”：

• 第一次：预热运行，丢弃结果
• 第二次：正式运行，记录99%Line、TPS、错误率
• 第三次：再次运行，验证结果稳定性（两次99%Line偏差<5%才认可）

基线报告必须包含：JMeter版本、JVM参数、压测机配置（CPU/内存/网卡）、被测服务版本、数据库连接池配置、缓存命中率。我们用Confluence模板固化这些字段，确保每次基线可追溯、可对比。

8. 最后一个，也是最容易被忽视的问题：压测目标不是“找出最大并发数”，而是“验证业务SLA的达成边界”

所有技术问题最终要回归业务。JMeter压测的终极目标，从来不是“我的系统能扛住5000并发”，而是“在双十一大促期间，用户下单平均响应时间≤1.5秒，成功率≥99.99%，这个SLA能否达成？”

这就要求压测设计必须与业务指标对齐。例如：

• 电商下单：核心指标是“下单成功响应时间≤1.5秒”，而非“HTTP 200返回时间”。因为200返回后，后端可能还在异步处理库存扣减、消息推送，用户实际感知的“下单完成”是前端跳转到成功页。所以，脚本必须包含“轮询订单状态接口”，直到返回status=success，才计为一次有效请求。
• 直播互动：核心指标是“弹幕从发送到观众端显示≤500ms”。这涉及CDN、WebSocket长连接、消息广播链路。压测脚本不能只发HTTP请求，必须用WebSocket Samplers模拟真实连接，并在客户端（用JSR223 Sampler）计算端到端延迟。

我坚持一个原则：压测脚本的每一行，都必须能在生产环境用户行为中找到对应。如果脚本里有个“随机等待3秒”，就必须有产品文档证明：用户在提交订单后，平均会停留3秒看成功提示；如果脚本里没有“网络弱状态模拟”，就必须承认：我们的SLA承诺，不包含4G弱网场景。

这8个问题，我写下来不是为了让你记住答案，而是希望下次你面对飘红的99%Line时，能本能地问：是线程组配置在骗我？是CSV数据在循环复用？是JMeter本机在端口耗尽？还是……我们的业务SLA，本来就没定义清楚？

压测不是技术炫技，而是用代码写的业务承诺书。每一个配置项，都是对这份承诺的校验。