Spring Boot REST接口压测首选JMeter，需确保测试环境贴近生产（同规格服务器、百万级真实数据、关闭调试端点、分离压测与被测机器）；脚本配置含线程组、HTTP请求、请求头、断言及监听器；关注吞吐量、90%响应时间、错误率突增点，并结合JVM监控分析瓶颈。
Spring Boot 的 REST 接口压测，核心是用工具模拟真实并发请求，观察系统在高负载下的响应能力。JMeter 是最常用、上手快、结果直观的选择，不需要改代码，也不依赖 Spring Boot 特性本身。
准备测试环境
压测结果是否可信，关键看环境是否贴近生产：
- 后端服务部署在与生产同规格的服务器（CPU、内存、JVM 参数一致）
- 数据库用真实数据量（至少百万级），避免空库或单条记录导致响应失真
- 关闭开发时启用的调试端点（如 /actuator/env、/actuator/beans），防止干扰主线程
- JMeter 运行机器和被测服务尽量不在同一台物理机，避免资源争抢
用 JMeter 搭建基础压测脚本
以一个典型的 GET 接口 GET /api/products 为例：
- 新建 Thread Group：设线程数 100（模拟 100 并发用户），Ramp-up 时间 20 秒（每秒加 5 个用户）
- 添加 HTTP Request：协议选 http，服务器名称填服务 IP 或域名，端口 8080，路径写 /api/products
- 添加 HTTP Header Manager：设置 Accept: application/json 和 Content-Type: application/json（适配 Spring Boot 默认返回格式）
- 添加断言（Assert）：用“响应断言”，检查响应码是否为 200，或响应体是否包含 "products"
- 添加监听器：至少加“聚合报告”（看吞吐量、平均响应时间、错误率）和“查看结果树”（调试用，正式压测前建议关闭）
执行与结果分析要点
别只盯着“有没有报错”，重点看三类指标：
- 吞吐量（TPS）：比如从 50 TPS 掉到 20 TPS，说明系统已到瓶颈，不是单纯看数字高低
- 90% 响应时间：比平均值更有参考价值；若从 200ms 升至 1200ms，即使没报错，用户体验也已恶化
- 错误率突增点：比如并发升到 150 时错误率跳到 8%，说明这个并发量就是当前服务的临界值
- 配合监控看 JVM：用 Actuator 的 /actuator/metrics/jvm.memory.used 或 Prometheus + Grafana 查 GC 频次、堆内存使用曲线
进阶建议
让压测更贴近真实场景：
- 用 CSV Data Set Config 读取不同用户的 token 或 ID，避免所有请求都走同一个缓存 key
- 对 POST 接口，用 JSON Extractor 提取上一个响应里的 ID，作为下一个请求的 body 参数，模拟链路调用
- 用 JSR223 Timer 插入随机停顿（如 1–3 秒），模拟用户真实操作间隔
- 命令行运行更稳定：./jmeter -n -t product-test.jmx -l result.jtl -e -o report，生成 HTML 报告便于分享
