系统在单位时间内能处理的请求数量 —— 衡量系统承载能力的核心指标
并发越高，单位时间内能处理的请求越多。但过高会带来上下文切换开销，反而降低吞吐量。
RT 越短，同样并发下吞吐量越高。优化 DB 查询、缓存命中率可直接提升吞吐量。
磁盘 I/O、网络带宽是常见瓶颈。异步 I/O、NIO 可以显著提升吞吐量。
DB 连接数不足时会产生等待，是压测中最常见的吞吐量瓶颈之一。
高并发下锁争用和频繁 GC 会产生 Stop-the-World，导致吞吐量陡降。
大请求体占用带宽，序列化/反序列化消耗 CPU，同等时间内处理请求数减少。
选定要评估的接口/功能，明确是读多写少还是混合场景，决定测试数据集规模。
常用工具：JMeter、wrk、ab（Apache Bench）、k6、Gatling。设置并发用户数、Ramp-up 时间，模拟真实流量形态。
在系统稳定运行阶段（排除预热期）统计：完成的请求总数 ÷ 统计时长 = TPS/QPS。
逐步增加并发，观察吞吐量变化。曲线会经历：上升 → 平台期 → 拐点（系统过载）→ 下降三个阶段。
吞吐量开始下降前的最高点即为系统最大吞吐量。此时 RT 还在可接受范围内，是最佳运行点。
总 TPS 中需剔除失败请求。高错误率下的高 TPS 毫无意义。有效吞吐量 = 成功请求 ÷ 统计时长。
💡 随并发增大：吞吐量先上升，到达 最优工作点 后趋于平稳，最终因资源争用而 下降 ——这是设计容量规划的关键依据