测试工具选型：JMeter、Locust、wrk 深度对比与实战策略
做性能测试这么多年，我经常被问到同一个问题：「到底该用哪个工具？」
说实话，没有银弹。每个工具都有自己的脾气。选错了，你可能会在压测过程中被工具本身坑得焦头烂额。今天我就把 JMeter、Locust、wrk 这三把「兵器」掰开揉碎了讲清楚。
核心观点：选工具不是选「最好的」，而是选「最适合你当前场景的」。吞吐测试的成败，一半在工具选型。
1. JMeter：老牌全能选手
JMeter 是我用得最久的工具。它最大的优势就是「啥都能干」。HTTP、JDBC、JMS、FTP……你能想到的协议，它基本都支持。
我个人习惯用 JMeter 做复杂的业务场景压测。比如一个电商下单流程，需要先登录、加购物车、下单、支付，中间还有参数关联和断言。这种场景用 JMeter 的 GUI 拖拽式配置，确实方便。
核心特性
- 多协议支持：HTTP/HTTPS、WebSocket、gRPC、JDBC、JMS 等
- 丰富的组件生态：定时器、前置处理器、后置处理器、断言、监听器
- 分布式压测：支持 Master-Slave 模式，可以横向扩展
- 结果报告：内置 HTML 报告生成，也可以对接 Grafana + InfluxDB
我的经验：JMeter 的 GUI 模式只适合脚本调试。真正压测时一定要用命令行模式（jmeter -n -t script.jmx -l result.jtl），否则 GUI 本身会吃掉大量资源，影响压测结果。
避坑指南
我曾经在一个项目中用 JMeter 压测 5000 并发，结果 Master 节点自己先挂了。后来发现是 GUI 模式没关，再加上监听器里开了太多图表。记住：生产级压测，关掉所有监听器，只用命令行。
2. Locust：Python 玩家的利器
Locust 是我后来才接触的。说实话，一开始我挺抗拒的——毕竟 JMeter 用了那么多年。但有一次需要压测一个 WebSocket 服务，JMeter 的配置太繁琐了，我就试了试 Locust。
结果真香。
核心特性
- 纯 Python 脚本：用代码定义用户行为，灵活度极高
- 协程并发：基于 gevent，单机并发能力远超 JMeter
- Web UI 实时监控：压测过程中可以实时看到 RPS、响应时间、错误率
- 分布式模式：Master + Worker 架构，Worker 可以动态加入
你想想看，如果你团队里都是 Python 开发者，用 Locust 简直无缝衔接。写一个压测脚本就跟写单元测试一样自然。
代码示例：一个简单的 Locust 脚本
from locust import HttpUser, task, between
class WebsiteUser(HttpUser):
wait_time = between(1, 5) # 用户等待时间 1-5 秒
@task(3) # 权重 3
def view_homepage(self):
self.client.get("/")
@task(1) # 权重 1
def search(self):
self.client.post("/search", json={"q": "性能测试"})注意：Locust 的协程模型虽然并发高，但遇到 CPU 密集型操作（比如加解密、复杂计算）时，性能会急剧下降。因为 gevent 的协程本质上是单线程的，CPU 密集型任务会阻塞事件循环。
3. wrk：轻量级「火箭筒」
wrk 是我做快速摸底测试时的首选。它有多轻？一个二进制文件，不到 1MB，跑起来就能压。
我记得有一次线上出了性能问题，需要立刻验证一个优化方案的效果。我直接在服务器上 apt install wrk，30 秒就出了结果。如果用 JMeter，光装 JDK 就得 5 分钟。
核心特性
- 极致的性能：基于 libuv 和 Redis 的 ae 事件循环，单机可以轻松打出 10 万+ QPS
- Lua 脚本扩展：支持自定义请求、参数化、校验
- 简洁的 CLI：一行命令就能跑起来
- 低资源消耗：压测本身几乎不消耗 CPU 和内存
我的用法：wrk 适合做「毛估估」测试。比如上线前快速验证接口的极限 QPS，或者对比两个版本的性能差异。但它不适合做复杂的业务场景压测，因为 Lua 脚本写复杂逻辑太痛苦了。
实战命令
# 基础用法：10 个线程，100 个连接，压 30 秒
wrk -t10 -c100 -d30s http://target.com/api
# 带 Lua 脚本：自定义请求体
wrk -t4 -c200 -d60s -s post.lua http://target.com/api4. 工具对比：一张表说清楚
| 维度 | JMeter | Locust | wrk |
|---|---|---|---|
| 协议支持 | 极丰富（HTTP、JDBC、JMS、gRPC 等） | 中等（HTTP、WebSocket，可扩展） | 有限（仅 HTTP/HTTPS） |
| 脚本语言 | XML（GUI 配置） | Python | Lua |
| 单机并发能力 | 中等（线程模型，5000 并发以上吃力） | 高（协程模型，轻松上万） | 极高（事件驱动，10 万+） |
| 学习曲线 | 平缓（GUI 拖拽） | 中等（需要 Python 基础） | 陡峭（CLI + Lua） |
| 分布式支持 | 成熟（Master-Slave） | 成熟（Master-Worker） | 无原生支持 |
| 结果报告 | 丰富（HTML、CSV、Grafana） | 实时 Web UI + CSV | 终端输出 + 简单统计 |
| 适用场景 | 复杂业务场景、多协议、CI/CD 集成 | Python 技术栈、WebSocket、高并发 | 快速摸底、极限压测、对比测试 |
5. 选型策略：我的决策框架
说了这么多，到底怎么选？我总结了一个「三问决策法」：
- 你的场景有多复杂？
- 简单接口压测 → wrk
- 多步骤业务流程 → JMeter
- 自定义协议或复杂逻辑 → Locust
- 你的团队技术栈是什么？
- Java 团队 → JMeter（生态成熟，社区资源多）
- Python 团队 → Locust（代码即脚本，维护成本低）
- 运维/DevOps 团队 → wrk（轻量，适合快速验证）
- 你的压测目标是什么？
- 极限 QPS 摸底 → wrk
- 稳定性测试（长时间压测）→ JMeter 或 Locust
- 性能回归（CI/CD 中自动执行）→ JMeter（有成熟的 Jenkins 插件）
我的建议：不要只学一个工具。我个人的工具箱里，JMeter、Locust、wrk 都有。日常工作中，我 60% 的场景用 JMeter，30% 用 Locust，10% 用 wrk。每个工具都有自己的「舒适区」。
6. 知识体系总览
下面这张图是我自己整理的测试工具选型知识体系，你可以把它当作决策地图：