前言：为什么你压测的结果不可信
先讲个真实翻车现场。上个月我给公司一个 Go 服务做上线前压测，拿着 wrk 一顿猛打，报告显示 8 万 QPS、P99 只有 12ms，我差点就写上「性能达标」交差了。结果上线第二天，用户一多，服务直接超时报警。后来排查才发现：wrk 默认只测 GET 接口，而我压的那个接口是 POST，压测请求压根没打对地方——我测了个寂寞。
这事之后我把市面上主流的压测工具全折腾了一遍：k6、wrk、hey、vegeta、oha，每个都在同一台机器上、对同一个接口跑过。今天这篇就把这些工具的真实体验写出来，包括它们的坑和适用场景。评测时间 2026 年 8 月，工具版本以各仓库最新稳定版为准。
一句话结论先放这：没有最好的压测工具，只有最合适的场景。k6 适合正规军、wrk 适合单机极限、hey 适合随手一测、vegeta 适合管道化压测、oha 适合想兼容 HTTP/2 的 wrk 用户。下面逐个说。
概览：五个工具一张表看清
| 工具 | 语言 | 脚本能力 | 分布式 | 报告 | 一句话定位 |
|---|---|---|---|---|---|
| k6 | Go（脚本用 JS） | 强（JS + 自定义检查） | ✅ 原生支持 | 强（内置 + 导出） | 正规军，压测平台级选手 |
| wrk | C | 中（Lua 脚本） | ❌ | 弱（纯文本） | 单机性能之王 |
| hey | Go | 无 | ❌ | 简单（文本 + 可选 JSON） | 随手一测，5 秒上手 |
| vegeta | Go | 弱（命令行参数） | 半（多机攻击器） | 中（可管道化处理） | UNIX 哲学，攻击/报告分离 |
| oha | Rust | 弱 | ❌ | 中（终端彩显 + JSON） | 现代版 wrk，支持 HTTP/2 |
逐个深聊：每个工具的亮点与坑
k6：压测界的「正规军」
亮点：k6 是我现在主力推荐的工具，没有之一。脚本用 JavaScript 写，意味着你可以描述完整的用户行为——登录、拿 token、带 cookie 请求、断言响应码、检查响应时间，一套脚本把业务场景完整模拟出来。它有内置的 check() 函数做断言，跑完直接告诉你「97.2% 的请求通过了检查」，比一堆裸 QPS 数字有用得多。分布式压测是原生能力，Grafana Cloud 或者自己起个 k6-operator 就能横向扩展。报告输出有 HTML/JSON 多种格式，还能直接对接 Grafana 画图。
不足：JS 解释层有性能开销，单机打极限吞吐时比 wrk 弱一截，我实测同一个接口 k6 单机大概能打到 wrk 的 60-70% 的量级。另外学习曲线陡，光是搞懂 VU（虚拟用户）和 RPS（每秒请求数）两种模型就够新手喝一壶的。想 30 秒上手？别找它。
wrk：单机压测的性能天花板
亮点：wrk 是我见过把「简单 + 极致」平衡得最好的工具。一个二进制文件，一条命令，利用多核 + 非阻塞 IO，单机就能打出极高的吞吐。它对标的就是「这台机器到底能扛多少」这个终极问题。Lua 脚本能做一些定制（自定义请求头、请求体、甚至写个简单的概率分流），虽然不如 JS 强大，但应付 80% 的压测场景够了。想压静态页、纯 GET 接口、或者测网关极限，wrk 永远是第一选择。
不足：我开头的翻车现场就是它造成的——wrk 默认的压测请求非常「裸」，不带任何业务语义。POST 请求、带 body、带 header、多步骤流程，都得自己写 Lua，而 Lua 的调试体验一言难尽。报告只有纯文本的延迟分布，没有断言、没有检查点、没有趋势图。压完你得自己拿 awk 处理输出。另外不支持 HTTP/2，2026 年了这有点说不过去。
hey：5 秒上手的「随手测」神器
亮点：hey 的前身是 boom，一个 Go 写的压测小工具。它的核心优势就俩字：简单。想验证「这个接口通不通、大概多快」，一行命令搞定：hey -n 10000 -c 100 https://api.example.com/v1/health。它支持自定义 header、body、POST 数据，够日常排查用。输出带漂亮的柱状图式的延迟分布（终端里显示），比 wrk 的纯文本友好多了。
不足：功能天花板很低。没有脚本能力，没有断言，不支持 HTTP/2（虽然 Go 底层库支持但 hey 用起来有限制），压测复杂业务场景完全无能为力。它就是个「快测一下」的工具，别指望它干正经压测的活。我一般拿它做联调自测，压测报告从来不用它出。
vegeta：UNIX 哲学的信徒
亮点：vegeta 的设计理念非常 Geek：攻击（attacker）和报告（reporter）是两个独立的程序，中间用管道连接。echo "GET http://target" | vegeta attack -rate 1000 | vegeta report——标准的 Unix 风格，每个环节都能替换、能组合、能持久化。攻击结果可以落盘成二进制文件，事后随时重新生成报告，还能用 vegeta plot 输出 HTML 图表。对喜欢命令行管道的工程师来说，这种「可组合性」是其他工具给不了的。
不足：脚本能力基本为零，场景定制全靠命令行参数堆。想模拟多步骤业务流？vegeta 会很痛苦。它的报告格式偏工程师向，给老板汇报基本得自己再加工。分布式压测要自己写脚本编排多台机器的 attack 进程，不算原生支持。属于「懂的人爱死，新手用不明白」的类型。
oha：更现代的 wrk 替代品
亮点：oha 是 Rust 写的，设计目标就是「做一个支持 HTTP/2 的 wrk」。它继承了 wrk 的单机高性能，同时带来了现代特性：HTTP/2 支持、彩色终端输出、延迟分布的 ASCII 图、JSON 报告导出。我的实测里它的单机吞吐和 wrk 基本持平，但用起来舒服得多——至少不用为了看个分布图去装 gnuplot。
不足：和 wrk 一样是「裸请求」型工具，脚本能力缺失，复杂场景玩不转。生态也还小，文档和社区比 k6 差远了。如果你的服务全走 HTTP/1.1，那它和 wrk 的差距其实没那么大。
星级评分：六维度一表定胜负
| 维度 | k6 | wrk | hey | vegeta | oha |
|---|---|---|---|---|---|
| 上手难度（分越高越易上手） | ⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| 性能上限 | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| 脚本能力 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐ | ⭐⭐ | ⭐⭐ |
| 功能完整度 | ⭐⭐⭐⭐⭐ | ⭐⭐ | ⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ |
| 分布式支持 | ⭐⭐⭐⭐⭐ | ⭐ | ⭐ | ⭐⭐ | ⭐ |
| 报告输出 | ⭐⭐⭐⭐⭐ | ⭐ | ⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ |
适用场景：选哪个，看你要干嘛
选 k6，如果：你要压的是完整业务场景（登录→下单→支付这种多步骤链路），需要断言和阈值检查，或者想接入 CI/CD 做性能回归。它是唯一能当「压测平台」用的。
选 wrk，如果：你想知道这台裸机器/裸服务的性能天花板在哪，压的是纯 GET 或简单接口，追求单机最大吞吐。性能压测的「底线测试」用它准没错。
选 hey，如果：你只是联调时想确认接口响应时间大概多少、通不通，不想装任何东西、不想读任何文档。30 秒解决问题。
选 vegeta，如果：你是个命令行重度用户，喜欢把压测结果落盘、管道化处理、反复生成报告，或者需要在多台机器上手动编排攻击。
选 oha，如果：你的服务上了 HTTP/2，又想要 wrk 那种单机极限性能，还想有个好看点的终端输出。
FAQ
Q: k6 和 wrk 到底怎么选？
看你要回答什么问题。问「我的服务在真实用户行为下能不能扛住」→ 选 k6，它模拟的是业务场景；问「这台服务器裸性能到底多少」→ 选 wrk，它压的是机器极限。我的建议是两者都装：k6 出正式压测报告，wrk 做极限摸底。
Q: 压测工具本身会不会成为瓶颈，导致结果不准？
会，而且这是最常见的压测误区。单机压测时，压测工具所在机器的 CPU/网络会成为瓶颈，尤其是 k6 这种带 JS 解释器的。正确做法是：压测机和服务机分开部署，压测前先用 wrk 或 oha 探一下压测机自身的极限，确保它远高于目标压测值。
Q: 需要分布式压测，选哪个？
k6 是唯一原生支持分布式的（k6-operator 或 Grafana Cloud），能把多台机器的负载汇聚成一份报告。vegeta 可以手动在多台机器跑 attack 再合并结果，但需要自己写编排。wrk/hey/oha 都只能单机。
Q: 压测结果里 QPS 和延迟该信哪个？
两个都信，但别只看平均值。QPS 看吞吐能力，P99/P95 延迟才是用户体验的真相——平均值会被大量快速请求拉低，掩盖尾部延迟问题。上线前压测至少要看 P99 延迟曲线，而不是平均延迟。
总结：我的主力组合
我现在的工作流是：k6 出正式报告 + wrk 做极限摸底 + hey 随手排查。三个工具各司其职，覆盖了从「随口问一句接口快不快」到「上线前正式压测出报告」的全部场景。
最后提醒一句：压测工具只是手段，压出来的问题还得靠性能剖析工具去定位。配合我之前写过的 Python 性能剖析三件套：py-spy、Scalene、memray 实战对比、FastAPI 性能调优实战：从 1000 到 15000 req/s 和 C#/.NET 性能诊断工具链深度评测，一套完整的「压测→定位→优化→复测」闭环就齐了。你压测时踩过什么坑？评论区聊聊。