性能测试这件事，说到底是给系统"上强度"之前的一次全面体检。我做了十多年测试，见过太多团队在压测工具选型上反复横跳：有人抱着 JMeter 不放，有人一窝蜂转向 k6，还有人用 Locust 写了几千行 Python 脚本最后发现维护成本比业务代码还高。工具本身没有绝对的好坏，关键在于它跟你的团队技术栈、压测场景、报告需求是否匹配。这篇盘点把 2026 年市面上 13 款主流压测工具拉出来逐个拆解，从协议支持、脚本编写方式、分布式能力、报告可视化到实际踩坑点，尽量讲透。不管你是刚接触性能测试的新人，还是正在做工具迁移决策的资深工程师，都能从中找到适合自己的那一款。
1. 选压测工具之前，先搞清楚你在压什么
很多人一上来就问"哪个工具最好用"，这个问题本身就问错了。压测工具的选择取决于你要压什么、谁来写脚本、报告给谁看。我见过一个团队用 JMeter 压 gRPC 接口，折腾了两周插件最后还是换了工具；也见过有人用 k6 压一个需要复杂前置数据构造的业务流，脚本写到怀疑人生。所以先花几分钟把下面几个维度想清楚，比盲目对比工具参数有用得多。
1.1 协议覆盖范围决定了工具的下限
压测工具支持的协议种类，直接决定了它能不能用在你的项目上。HTTP/HTTPS 是最基础的，几乎所有工具都支持。但一旦涉及 gRPC、WebSocket、MQTT、Dubbo、Thrift 这些协议，可选范围就大幅缩小了。
JMeter 靠插件生态覆盖了大部分协议，但插件质量参差不齐，有些插件几年没更新了。k6 原生支持 HTTP、WebSocket、gRPC，扩展性靠 Go 编写的扩展模块。Locust 基于 Python 的 requests 库，理论上只要 Python 能调的协议它都能压，但需要自己封装。Gatling 原生支持 HTTP、WebSocket、SSE，对 gRPC 的支持还在完善中。
实操建议：如果你的系统涉及多种协议混合压测，优先考虑 JMeter 或 Locust，它们的扩展成本相对可控。如果只压 HTTP 接口，k6 和 Gatling 的体验会更好。
1.2 脚本编写方式决定了团队的上手成本
脚本编写方式是选型时最容易被低估的因素。JMeter 用 GUI 拖拽元件，上手快但复杂场景维护困难；k6 用 JavaScript 写脚本，对前端背景的测试人员友好；Locust 用 Python，适合有开发能力的团队；Gatling 用 Scala DSL，学习曲线陡但表达能力强。
我个人的经验是：如果团队里测试人员以功能测试转岗为主，JMeter 的 GUI 模式能让他们快速出活；如果团队有专职性能测试开发，代码化工具（k6、Locust、Gatling）在版本管理和 CI 集成上优势明显。别小看这个差异，我见过一个团队强行让功能测试人员写 Locust 脚本，结果每次需求变更都要找开发帮忙改脚本，效率反而更低。
1.3 报告能力决定了压测结果能不能说服人
压测做完了，报告是给谁看的？给开发看，需要详细的响应时间分布、错误率、吞吐量曲线；给领导看，需要简洁的结论和对比数据；给运维看，需要资源占用和瓶颈定位信息。
JMeter 的 HTML 报告模板经过多年迭代已经比较完善，但默认样式确实不太好看，社区有汉化模板可以替换。k6 的报告输出比较简洁，适合 CI 流水线里快速判断通过与否，深度分析需要配合 Grafana 等工具。Gatling 的报告是公认最好看的，自带响应时间分布图和请求链路分析。Locust 的 Web UI 实时性好，但历史报告需要自己对接存储。
2. 13 款主流压测工具逐个拆解
下面按工具类型分组，逐个讲清楚每款工具的核心特点、适用场景和实际使用中的坑。分组不是绝对的，有些工具跨类别，我按主要使用方式来归类。
2.1 JMeter：绕不开的行业基准
JMeter 是 Apache 基金会的开源项目，Java 编写，跨平台运行。它的核心优势是生态成熟、资料丰富、插件众多。你遇到的大部分压测需求，网上都能找到现成的解决方案。
安装配置这块，JMeter 需要先装 JDK，推荐 JDK 8 或 JDK 11，JDK 17 以上部分插件兼容性有问题。下载官方二进制包解压后，配置JMETER_HOME环境变量，把bin目录加入PATH就能用。Windows 下双击jmeter.bat，Linux/Mac 下执行jmeter.sh。内存不够的话改bin/jmeter文件里的HEAP参数，默认 1G 压高并发容易 OOM。
脚本编写方面，JMeter 的元件体系包括线程组、取样器、逻辑控制器、断言、监听器等。一个典型的压测脚本结构是：线程组设置并发数和循环次数，HTTP 请求取样器配置接口地址和参数，响应断言校验返回结果，聚合报告收集数据。
<!-- JMeter 线程组配置示例 --> <ThreadGroup> <stringProp name="ThreadGroup.num_threads">100</stringProp> <stringProp name="ThreadGroup.ramp_time">10</stringProp> <boolProp name="ThreadGroup.scheduler">true</boolProp> <stringProp name="ThreadGroup.duration">300</stringProp> </ThreadGroup>BeanShell 断言是 JMeter 里用得最多的脚本断言方式，可以写 Java 代码校验响应。比如校验返回 JSON 里某个字段的值：
// BeanShell 断言示例 import org.json.JSONObject; String response = prev.getResponseDataAsString(); JSONObject json = new JSONObject(response); if (json.getInt("code") != 200) { Failure = true; FailureMessage = "返回码不是200，实际为：" + json.getInt("code"); }While 控制器配合条件判断可以实现轮询等待场景，比如提交任务后不断查询状态直到完成。动态调整 QPS可以通过 Constant Throughput Timer 或者用 BeanShell 脚本动态修改线程数来实现，后者更灵活但需要小心线程安全问题。
上传文件场景用 HTTP 请求里的"文件上传"选项卡，注意勾选"Use multipart/form-data"。录制 HTTPS 脚本需要先配置 JMeter 的代理和证书，在浏览器里导入 JMeter 的 CA 证书后就能录制。Cookie 管理用 HTTP Cookie Manager 元件，可以自动管理会话，也可以手动添加固定 Cookie。
分布式压测是 JMeter 的强项，一台 master 控制多台 slave 就能突破单机并发限制。配置时注意 slave 机器的 JMeter 版本要一致，防火墙要放行 1099 和 50000 端口。
踩坑提醒：JMeter GUI 模式只用来写脚本和调试，真正压测必须用命令行模式
jmeter -n -t script.jmx -l result.jtl -e -o report，否则 GUI 本身会消耗大量资源影响压测结果。
2.2 k6：为 CI/CD 而生的现代压测工具
k6 是 Grafana Labs 维护的开源工具，用 Go 编写，脚本用 JavaScript。它的设计理念就是"测试即代码"，非常适合集成到 CI/CD 流水线里。
k6 的脚本结构很清晰，一个典型的 HTTP 压测脚本长这样：
import http from 'k6/http'; import { check, sleep } from 'k6'; export const options = { stages: [ { duration: '30s', target: 50 }, { duration: '1m', target: 100 }, { duration: '30s', target: 0 }, ], thresholds: { http_req_duration: ['p(95)<500'], http_req_failed: ['rate<0.01'], }, }; export default function () { const res = http.get('https://api.example.com/users'); check(res, { 'status is 200': (r) => r.status === 200, 'response time < 500ms': (r) => r.timings.duration < 500, }); sleep(1); }k6 的thresholds机制是它的一大亮点，可以直接在脚本里定义性能门槛，CI 流水线里跑完自动判断通过还是失败，不需要人工看报告。stages配置支持阶梯式加压，模拟真实流量爬坡场景。
k6 的分布式能力相对弱一些，官方推荐用 k6 Operator 在 Kubernetes 里跑分布式压测，配置门槛比 JMeter 高。但单机性能很强，一台 8 核 16G 的机器跑几千并发问题不大。
实操心得：k6 的
sleep(1)是模拟用户思考时间，但要注意它不占用 VU 资源。如果你需要精确控制请求间隔，用sleep就够了；如果需要控制每秒请求数，得用constant-arrival-rate执行器。
2.3 Locust：Python 技术栈的首选
Locust 是开源 Python 压测工具，最大特点是脚本用纯 Python 写，扩展性极强。如果你的团队 Python 技术栈为主，Locust 几乎是自然选择。
Locust 的脚本核心是定义用户行为：
from locust import HttpUser, task, between class WebsiteUser(HttpUser): wait_time = between(1, 3) def on_start(self): self.client.post("/login", json={"username": "test", "password": "123456"}) @task(3) def view_items(self): self.client.get("/items") @task(1) def create_order(self): self.client.post("/orders", json={"item_id": 1, "quantity": 2})@task(3)里的数字是权重，表示这个任务被执行的概率是另一个的 3 倍。wait_time控制用户思考时间。on_start在每个用户启动时执行一次，适合做登录等前置操作。
Locust 的Web UI实时性很好，能看到实时 RPS、响应时间、失败率曲线。分布式模式下一台 master 加多台 worker，通过--master和--worker参数启动。
Locust 的坑主要在性能上：Python 的 GIL 限制了单进程的并发能力，高并发场景需要开多个 worker 进程。另外 Locust 的 HTTP 客户端基于 requests 库，连接池配置不当容易出现端口耗尽问题。
2.4 Gatling：报告最漂亮的压测工具
Gatling 是法国公司开源的压测工具，基于 Scala 和 Akka 构建，后来推出了 Java DSL。它的报告是公认最好看的，自带响应时间分布图、请求链路瀑布图、活跃用户曲线。
Gatling 的 Java DSL 脚本示例：
public class BasicSimulation extends Simulation { HttpProtocolBuilder httpProtocol = http .baseUrl("https://api.example.com") .acceptHeader("application/json"); ScenarioBuilder scn = scenario("BasicScenario") .exec(http("GetUsers") .get("/users") .check(status().is(200))) .pause(1); { setUp( scn.injectOpen( rampUsers(100).during(Duration.ofSeconds(30)), constantUsersPerSec(20).during(Duration.ofMinutes(2)) ) ).protocols(httpProtocol); } }Gatling 的injection模型比 JMeter 的线程组更灵活，支持多种加压策略组合。checks机制类似断言，可以校验响应状态、内容、响应时间等。
Gatling 的分布式能力靠 Gatling Enterprise（商业版）或者自己用 Docker 编排。开源版单机性能不错，但报告生成会消耗较多内存，压测机配置要够。
2.5 wrk 和 wrk2：轻量级 HTTP 压测利器
wrk 是用 C 写的轻量级 HTTP 压测工具，单机性能极强，适合快速验证接口吞吐量。wrk2 是 wrk 的改进版，修正了 wrk 的延迟统计问题，能输出更准确的延迟分布。
wrk 的基本用法：
wrk -t12 -c400 -d30s --latency https://api.example.com/users-t12是 12 个线程，-c400是 400 个连接，-d30s压 30 秒，--latency输出延迟统计。wrk 支持 Lua 脚本扩展，可以自定义请求和校验逻辑。
wrk 的局限很明显：只支持 HTTP，不支持复杂场景编排，报告只有命令行输出。它适合做接口级别的快速压测，不适合做端到端的业务流压测。
2.6 ab：最古老的压测工具
ab（ApacheBench）是 Apache 自带的压测工具，几乎每台 Linux 机器上都有。用法极其简单：
ab -n 10000 -c 100 https://api.example.com/users-n是总请求数，-c是并发数。ab 的优点是零依赖、上手快，缺点是只支持 HTTP/1.0，不支持 Keep-Alive，压测结果偏悲观。它适合做最简单的接口验证，正式压测不建议用。
2.7 Vegeta：Go 编写的命令行压测工具
Vegeta 是 Go 编写的 HTTP 压测工具，命令行操作，支持恒定速率压测。它的特点是能精确控制每秒请求数，适合做稳定性测试。
echo "GET https://api.example.com/users" | vegeta attack -rate=100 -duration=30s | vegeta reportVegeta 支持多种输出格式，包括 JSON、CSV、HTML 图表。它的-rate参数控制每秒请求数，比 JMeter 的线程模型更直观。
2.8 Tsung：老牌多协议压测工具
Tsung 是 Erlang 编写的开源压测工具，支持 HTTP、WebSocket、MQTT、XMPP 等多种协议。它的分布式能力很强，单集群可以模拟百万级并发。
Tsung 的配置用 XML 文件，学习曲线较陡。它的报告是 HTML 格式，包含详细的统计图表。Tsung 的社区活跃度不如 JMeter，资料相对少一些。
2.9 Artillery：Node.js 生态的压测工具
Artillery 是 Node.js 编写的压测工具，脚本用 YAML 或 JavaScript。它的特点是上手快、报告清晰，适合 Node.js 技术栈的团队。
config: target: "https://api.example.com" phases: - duration: 60 arrivalRate: 10 scenarios: - flow: - get: url: "/users" - think: 1Artillery 支持插件扩展，可以对接 Datadog、New Relic 等监控平台。它的分布式能力靠 Artillery Pro（商业版）。
2.10 Siege：简单直接的压测工具
Siege 是 C 编写的 HTTP 压测工具，用法简单，支持基本的认证和 Cookie。它的特点是配置简单，适合快速验证。
siege -c 100 -t 30s https://api.example.com/usersSiege 的报告比较基础，只有请求数、成功率、响应时间等核心指标。它适合做简单的负载验证，复杂场景支持有限。
2.11 Locust4j：Java 版的 Locust
Locust4j 是把 Locust 的核心理念用 Java 重新实现的版本，适合 Java 技术栈团队。它的 API 设计跟 Locust 类似，但生态和资料远不如原版 Locust。
2.12 NeoLoad：商业压测工具的代表
NeoLoad 是 Tricentis 旗下的商业压测工具，提供 GUI 脚本录制、分布式压测、实时监控、AI 辅助分析等功能。它的优势是开箱即用、技术支持完善，缺点是价格不菲。
NeoLoad 适合预算充足、需要快速上手的企业团队。它的报告和监控集成做得很好，能直接对接 APM 工具定位瓶颈。
2.13 LoadRunner：老牌商业压测工具
LoadRunner 是 Micro Focus 旗下的商业压测工具，历史悠久，功能全面。它支持几乎所有主流协议，分布式能力强，报告详细。缺点是笨重、价格高、学习曲线陡。
LoadRunner 在金融、电信等传统行业还有大量存量用户，但互联网公司用得越来越少。
3. 工具选型的决策框架和对比表
讲了这么多工具，到底怎么选？我总结了一个决策框架，按优先级排序：
第一步：确定协议需求。只压 HTTP 的话选择面很宽；涉及 gRPC、WebSocket 等协议，优先考虑 JMeter、k6、Locust。
第二步：确定团队技术栈。Java 团队选 JMeter 或 Gatling；Python 团队选 Locust；Node.js 团队选 k6 或 Artillery；不想写代码选 JMeter GUI 或商业工具。
第三步：确定集成需求。要进 CI/CD 流水线，优先 k6、Gatling、Locust；要跟监控平台对接，看工具的插件生态。
第四步：确定预算。开源工具免费但需要自己维护；商业工具省心但价格高。
下面这张对比表把 13 款工具的核心维度拉平了看：
| 工具 | 脚本语言 | 协议支持 | 分布式 | 报告能力 | 上手难度 | 适用场景 |
|---|---|---|---|---|---|---|
| JMeter | GUI/Java | 极广 | 强 | 中 | 低 | 通用压测 |
| k6 | JavaScript | HTTP/WS/gRPC | 中 | 中 | 中 | CI/CD 集成 |
| Locust | Python | 依赖库 | 强 | 中 | 中 | Python 团队 |
| Gatling | Scala/Java | HTTP/WS | 中 | 强 | 高 | 报告要求高 |
| wrk/wrk2 | Lua | HTTP | 弱 | 弱 | 低 | 接口快速压测 |
| ab | 无 | HTTP | 弱 | 弱 | 低 | 简单验证 |
| Vegeta | 无 | HTTP | 弱 | 中 | 低 | 恒定速率压测 |
| Tsung | XML | 多协议 | 强 | 中 | 高 | 多协议大规模 |
| Artillery | YAML/JS | HTTP/WS | 中 | 中 | 低 | Node.js 团队 |
| Siege | 无 | HTTP | 弱 | 弱 | 低 | 简单负载 |
| Locust4j | Java | 依赖库 | 中 | 中 | 中 | Java 团队 |
| NeoLoad | GUI | 广 | 强 | 强 | 低 | 企业商业 |
| LoadRunner | GUI/脚本 | 极广 | 强 | 强 | 高 | 传统行业 |
选型提醒：不要只看工具本身，还要看社区活跃度和资料丰富度。JMeter 和 k6 的社区最活跃，遇到问题容易找到答案；一些小众工具出问题只能自己啃源码。
4. 从零搭建一次压测的完整流程
工具选好了，接下来讲怎么从零跑通一次完整的压测。我以 JMeter 为例，因为它的流程最典型，其他工具的思路类似。
4.1 环境准备和脚本编写
先装 JDK，再装 JMeter。JDK 版本建议 8 或 11，装完后java -version验证。JMeter 解压后配置环境变量，命令行执行jmeter -v能看到版本信息就说明装好了。
脚本编写在 GUI 里进行。新建测试计划，添加线程组，设置并发数、ramp-up 时间、循环次数。添加 HTTP 请求默认值元件，配置服务器地址和端口。添加 HTTP 请求取样器，配置接口路径和方法。添加响应断言，校验返回状态码。添加聚合报告和查看结果树监听器，方便调试。
调试阶段先用 1 个并发跑一遍，确认接口能通、断言能过。然后逐步增加并发，观察响应时间和错误率变化。
4.2 参数化和关联处理
真实压测需要模拟不同用户，这就涉及参数化。JMeter 用 CSV Data Set Config 元件读取 CSV 文件，把用户名、密码等数据参数化。文件路径建议用相对路径，方便脚本迁移。
关联处理是指从上一个请求的响应里提取数据，传给下一个请求。比如登录后拿到 token，后续请求都要带上。JMeter 用 JSON Extractor 或正则表达式提取器实现。
<!-- JSON Extractor 配置示例 --> <JSONPostProcessor> <stringProp name="JSONPostProcessor.referenceNames">token</stringProp> <stringProp name="JSONPostProcessor.jsonPathExprs">$.data.token</stringProp> <stringProp name="JSONPostProcessor.match_numbers">1</stringProp> </JSONPostProcessor>提取到的 token 用${token}在后续请求里引用。
4.3 命令行压测和报告生成
脚本调试好后，用命令行模式压测：
jmeter -n -t test.jmx -l result.jtl -e -o report-n非 GUI 模式，-t指定脚本，-l指定结果文件，-e压测后生成报告，-o指定报告输出目录。报告目录必须为空，否则会报错。
生成的 HTML 报告包含响应时间分布、吞吐量曲线、错误率统计等。默认报告是英文的，社区有汉化模板可以替换bin/report-template目录下的文件。
4.4 分布式压测配置
单机压不够就上分布式。master 机器上改jmeter.properties里的remote_hosts配置，写上所有 slave 的 IP 和端口。slave 机器上启动jmeter-server。master 执行：
jmeter -n -t test.jmx -R slave1_ip,slave2_ip -l result.jtl-R指定 slave 列表。压测结果会汇总到 master 的结果文件里。
分布式踩坑：slave 机器的 JMeter 版本必须和 master 一致，JDK 版本也要一致。CSV 参数文件要手动同步到每台 slave，JMeter 不会自动分发。网络延迟会影响压测结果，slave 和被测系统尽量在同一内网。
5. 压测中那些文档不会告诉你的坑
这部分是我这些年踩过的坑，文档里基本不会写，但实际压测中经常遇到。
5.1 端口耗尽和 TIME_WAIT 堆积
高并发压测时，压测机容易出现端口耗尽。Linux 默认的本地端口范围是 32768 到 60999，大概 28000 个端口。如果每个请求都新建连接，几万请求就能把端口用完。
解决办法是调整内核参数：
# 扩大本地端口范围 sysctl -w net.ipv4.ip_local_port_range="1024 65535" # 开启 TIME_WAIT 重用 sysctl -w net.ipv4.tcp_tw_reuse=1 # 减少 TIME_WAIT 时间 sysctl -w net.ipv4.tcp_fin_timeout=30JMeter 这边要开启 Keep-Alive，在 HTTP 请求里勾选"Use KeepAlive"，减少连接创建次数。
5.2 压测机自身成为瓶颈
压测机 CPU 跑满、内存不够、网络带宽打满，都会导致压测结果失真。压测前先用top、free、iftop看看压测机资源。JMeter 的 GUI 模式特别吃资源，正式压测一定用命令行。
判断压测机是否是瓶颈有个简单方法：看压测机的 CPU 使用率。如果压测机 CPU 超过 80%，而被测系统 CPU 很低，那瓶颈很可能在压测机这边。
5.3 断言写太复杂拖慢压测
JMeter 的断言是在压测线程里执行的，断言逻辑太复杂会拖慢压测速度。BeanShell 断言性能尤其差，因为它每次都要编译执行。能用 JSON 断言就用 JSON 断言，能用响应断言就用响应断言，实在不行再用 JSR223 断言配合 Groovy 脚本。
5.4 报告里的响应时间到底看哪个
JMeter 聚合报告里有平均值、中位数、90% 线、95% 线、99% 线、最大值、最小值。平均值容易被极端值拉偏，参考价值有限。我一般重点看 95% 线和 99% 线，这两个指标更能反映大多数用户的体验。
如果 95% 线是 200ms，99% 线是 2s，说明有 1% 的请求特别慢，需要重点排查。这种长尾问题往往比平均响应时间更值得关注。
5.5 压测环境和生产环境的差异
压测环境跟生产环境配置不一致，压测结果参考价值大打折扣。常见差异包括：数据库数据量不同、缓存命中率不同、网络拓扑不同、机器配置不同。
理想情况下压测环境应该跟生产环境 1:1 配置，但成本太高。折中方案是按比例缩容，比如生产环境 10 台机器，压测环境 2 台，压测结果乘以 5 估算生产容量。但要注意这种估算只在线性扩展假设下成立，实际系统往往有非线性瓶颈。
6. 压测脚本的版本管理和团队协作
压测脚本也是代码，需要版本管理。我见过太多团队把脚本放在某个人电脑里，人一走脚本就找不到了。
JMeter 的.jmx文件是 XML 格式，适合用 Git 管理。但要注意 GUI 保存时会重排 XML 结构，导致 diff 很乱。建议在 GUI 里编辑后，用命令行跑一遍确认没问题再提交。
参数化用的 CSV 文件也要纳入版本管理，但敏感数据（如真实用户密码）不要提交，用占位符代替，实际压测时替换。
团队协作方面，建议把压测脚本按业务模块拆分，每个人负责自己的模块，通过 CI 流水线定期跑回归压测。k6 和 Gatling 在这方面天然有优势，因为脚本本身就是代码，跟业务代码用同一套 CI 流程。
7. 云原生时代的压测新思路
现在越来越多系统跑在 Kubernetes 上，压测方式也在变化。传统压测机部署在集群外，压测流量经过入口网关，跟真实用户流量路径一致。但这种方式压测机本身可能成为瓶颈。
另一种思路是把压测工具也部署到 K8s 集群里，用 k6 Operator 或 JMeter Operator 动态创建压测 Pod。这种方式扩展性好，但压测流量走集群内网，跟真实用户路径有差异，需要根据压测目标选择。
还有一种做法是用服务网格的流量镜像功能，把生产环境的真实流量复制一份到压测环境。这种方式最接近真实场景，但需要服务网格支持，且要注意脱敏和流量控制。
云原生压测提醒：K8s 集群里的 Pod 资源限制（CPU/内存 limit）会影响压测结果。压测 Pod 的 limit 设置太低，压测机自己先被限流了。建议压测 Pod 不设 CPU limit，或者设得足够高。
8. 关于压测工具，我个人的几点体会
用了这么多年压测工具，我最大的体会是：工具只是手段，压测的目标是发现系统的性能瓶颈和容量上限。不要为了用某个工具而用某个工具，也不要迷信某个工具的压测结果。
JMeter 依然是通用场景下最稳妥的选择，生态成熟、资料丰富、遇到问题容易解决。k6 在 CI/CD 集成场景下体验最好，脚本即代码的理念很适合现代研发流程。Locust 适合 Python 团队，扩展性强但要注意性能调优。Gatling 的报告最好看，适合需要向非技术人员汇报的场景。
最后分享一个小技巧：不管用哪个工具，压测前先用小并发跑一遍完整流程，确认脚本逻辑没问题、断言能过、参数化生效。这一步能避免很多低级错误，比如参数文件路径写错、断言条件写反、关联提取失败等。我见过太多次压测跑了半小时才发现脚本有问题，白白浪费时间。
压测这件事，脚本写得好不好，直接决定了压测结果有没有参考价值。多花时间打磨脚本，比多压几轮更有意义。
