3. 性能测试工具选型：JMeter、Gatling、Locust、k6 的对比与选择
说实话，每次有团队问我「该用哪个压测工具」，我都觉得这是个好问题，但也是个容易踩坑的问题。
工具选错了，后面全白干。我见过有人用 JMeter 压 WebSocket 接口，结果自己先被 JMeter 的内存搞崩了。也见过团队用 Locust 压高并发，结果 Python 的 GIL 锁成了瓶颈。
所以这一章，咱们就把市面上最主流的四个工具——JMeter、Gatling、Locust、k6，掰开揉碎讲清楚。不吹不黑，只讲我实际用下来的感受。
核心观点：没有最好的工具，只有最适合你场景的工具。选型的关键，是搞清楚你的团队技术栈、被测系统类型、以及你希望压测脚本怎么维护。
3.1 四款工具的核心定位
先给个全景图，方便你快速建立认知。
3.2 逐个拆解：优缺点与适用场景
3.2.1 JMeter —— 老牌王者，但有点「重」
JMeter 是我最早接触的压测工具。说实话，它的 GUI 界面确实友好，拖拖拽拽就能写脚本。但用久了你会发现，它其实是个「双刃剑」。
优点：
- 生态最丰富。你想测什么协议，基本都有现成插件。
- 学习曲线平缓。不会写代码的人也能上手。
- 社区活跃，遇到问题基本都能搜到答案。
缺点：
- 资源消耗大。我曾经用 JMeter 压 2000 并发，结果 JMeter 自己先占用了 4G 内存。
- 脚本维护困难。GUI 生成的 XML 文件，你根本没法做版本对比。
- 分布式压测配置麻烦。我踩过这个坑，节点间时间不同步，结果数据全是乱的。
避坑指南：我曾经在压测一个 REST API 时，用 JMeter 的 GUI 模式跑了 1 小时，结果 GUI 渲染占用了大量 CPU，导致压测结果失真。记住：生产级压测一定要用 CLI 模式（非 GUI）。
3.2.2 Gatling —— 高并发场景下的「性能野兽」
Gatling 是我个人比较偏爱的工具。它的底层基于 Akka 和 Netty，说白了就是天生为高并发设计的。
优点：
- 性能极高。同样的并发量，Gatling 的资源消耗只有 JMeter 的 1/3。
- 报告生成漂亮。HTML 报告自带图表，直接可以给老板看。
- DSL 风格写脚本，可读性好。
缺点：
- 需要学 Scala。虽然语法不难，但对纯 Java 团队来说，多一门语言就是多一个门槛。
- 调试不方便。脚本写错了，报错信息有时候不够直观。
我的经验：如果你团队里有 Scala 或 Java 背景的人，Gatling 是压测 WebSocket 和 HTTP/2 的首选。我在一个金融项目中，用 Gatling 压测了 5000 并发，结果非常稳定。
3.2.3 Locust —— Python 党的最爱
Locust 最大的卖点就是「用 Python 写压测脚本」。如果你团队全是 Python 工程师，那 Locust 几乎是无缝衔接。
优点：
- 脚本就是 Python 代码，维护成本极低。
- 支持协程（gevent），单机并发能力不错。
- Web UI 实时查看结果，方便调试。
缺点：
- Python 的 GIL 锁是硬伤。虽然用了协程，但 CPU 密集型场景下性能会打折扣。
- 报告功能弱。默认的 Web UI 只能看实时数据，历史对比需要自己写脚本。
- 分布式压测时，主节点容易成为瓶颈。
注意：Locust 适合压测 I/O 密集型接口（比如 HTTP API），但不适合压测需要大量计算的场景。我试过用 Locust 压测一个加密接口，结果 CPU 直接跑满，并发上不去。
3.2.4 k6 —— 云原生时代的「轻量级选手」
k6 是近几年火起来的工具。它用 Go 语言编写，脚本却用 JavaScript。说白了，就是「用 JS 写脚本，用 Go 跑引擎」。
优点：
- 安装简单。一个二进制文件搞定，不像 JMeter 要装 Java。
- 资源消耗极低。我试过用 k6 压 3000 并发，内存占用不到 500MB。
- 原生支持 CI/CD 集成。可以轻松嵌入 Jenkins、GitLab CI。
缺点：
- 协议支持有限。目前主要支持 HTTP/1.1、HTTP/2、WebSocket，其他协议需要自己写扩展。
- 脚本调试体验一般。JavaScript 的异步处理有时候会让人头疼。
我的建议：如果你的压测场景主要是 HTTP API，并且希望把压测集成到流水线里，k6 是首选。我在一个电商项目中，用 k6 做了每日回归压测，效果非常好。
3.3 横向对比：一张表说清楚
| 维度 | JMeter | Gatling | Locust | k6 |
|---|---|---|---|---|
| 脚本语言 | XML（GUI） | Scala | Python | JavaScript |
| 单机并发能力 | 中等（约 2000） | 高（约 5000+） | 中等（约 3000） | 高（约 5000+） |
| 资源消耗 | 高 | 低 | 中等 | 极低 |
| 报告质量 | 一般（需插件） | 优秀（自带） | 一般（需扩展） | 良好（自带） |
| CI/CD 集成 | 一般 | 良好 | 一般 | 优秀 |
| 学习成本 | 低 | 中 | 低 | 中 |
| 协议支持 | 丰富（插件） | HTTP/WebSocket | HTTP/WebSocket | HTTP/WebSocket |
3.4 选型决策：我该怎么选？
嗯，这里我直接给结论，不绕弯子。
- 团队全是 Java 工程师，且需要测多种协议：选 JMeter。虽然它重，但生态最全。
- 团队有 Scala 背景，或者需要压测高并发 HTTP 服务：选 Gatling。性能好，报告漂亮。
- 团队全是 Python 工程师，且主要压测 HTTP API：选 Locust。脚本维护成本最低。
- 团队偏向 DevOps，希望把压测集成到 CI/CD 流水线：选 k6。轻量、高效、云原生。
最后说一句：工具只是手段，不是目的。我见过有人用 JMeter 写出了漂亮的压测脚本，也见过有人用 k6 写出了烂代码。关键还是你对压测本身的理解——场景设计、数据准备、结果分析，这些才是核心。
一个小建议：如果你刚开始搭建性能基线，我建议从 k6 或 Locust 入手。它们轻量、易上手，能让你快速跑通流程。等团队成熟了，再考虑 Gatling 或 JMeter 的深度能力。