ab仅适合快速冒烟测试或接口基线对比，因其不支持动态参数、登录态、复杂业务流，且受限于单进程同步I/O、文件描述符限制、无SNI支持及无法维持独立会话。
ab（Apache Bench）能快速发起 HTTP 并发请求，但它不是通用压力测试工具，也不支持动态参数、登录态或复杂业务流——别指望靠它测出真实服务瓶颈。
ab 命令基础用法与关键参数
最常用形式是 ab -n 1000 -c 100 http://example.com/：发送 1000 个总请求数，最大并发 100。注意 -n 是总数，不是每秒；-c 是并发连接数，不是线程数。
-
-k启用 HTTP Keep-Alive，避免反复建连，更贴近真实浏览器行为 -
-H "Authorization: Bearer xxx"可加请求头，但无法自动刷新 token -
-p file.txt发送 POST 数据，文件内容需是原始 body（不含 multipart boundary） -
-T "application/json"配合-p设置 Content-Type
ab 测试结果里哪些字段真有用
输出中真正值得关注的是：Time per request (mean)（平均延迟）、Requests per second（吞吐量）、Failed requests（失败数）。注意两个 Time per request：带 (mean, across all concurrent requests) 的才是单请求平均耗时；另一个是每个并发组的均值，容易误读。
- 若
Failed requests非零，先看Connect/Receive/Length/Exceptions分类，定位是网络层、响应体不一致，还是超时 -
Transfer rate单位是 KB/sec，不是请求速率，受响应体大小影响大，不能单独用来比性能 - 默认不显示各百分位延迟（如 p95），需配合
-g输出 TSVC 格式再用其他工具分析
ab 容易被忽略的限制和坑
ab 是单进程同步 I/O 实现，高并发下自身 CPU 或 socket 耗尽会导致测试失真——比如设 -c 2000，实际发出的并发可能远低于此，且 Requests per second 会异常偏低。
- Linux 默认单用户最大文件描述符数通常为 1024，
ab -c 2000会直接报错socket: Too many open files，需临时调高：ulimit -n 65536 - 不支持 HTTPS SNI 扩展（旧版 ab），访问多域名 HTTPS 站点可能握手失败
- 无法模拟思考时间（think time）、阶梯式增压（ramp-up）、或按比例混合多种请求路径
- 所有请求共用同一份 Cookie（即使有 Set-Cookie 响应），无法维持独立会话
真正要测后端承载力，ab 只适合做快速 smoke test 或接口 baseline 对比；涉及登录态、状态依赖、长连接或分布式场景，得换 wrk、hey，或者上 JMeter / k6。
