性能测试常被误解为"压一压看能扛多少人"，但真正成熟的性能工程远不止于此。它要回答的是三个层层递进的问题：系统在预期负载下表现如何、极限在哪里、以及瓶颈到底卡在哪一层。只做第一步，就等于把一场体检做成了量体重。 先说负载测试。这一步的核心不是把并发拉到天上，而是还原真实业务模型。电商大促的流量曲线是尖峰型，SaaS后台是工作日平峰型，直播场景则是脉冲型。用错模型压出来的数据，参考价值接近于零。建议从生产环境的访问日志中提取接口调用比例、思考时间分布和数据规模，再据此构造场景。 压力测试则要主动把系统推到崩溃边缘，观察它是"优雅降级"还是"雪崩式失效"。一个健康的系统在超载时应该拒绝新请求而不是拖垮已有连接，应该有熔断和限流兜底，恢复过程应该是可预期的。很多线上事故的根因不是容量不足，而是过载后的行为失控。 工具方面，JMeter依然是应用最广的开源选择，支持HTTP、HTTPS、TCP、WebSocket、JDBC等多种协议，插件生态成熟，且支持分布式压测以模拟大规模访问。对于追求脚本化和代码复用的团队，k6和Gatling提供了更现代的开发体验；而Apifox这类一体化平台，则把接口调试、Mock与压测串成了一条链路。 指标解读是最容易走偏的环节。平均响应时间几乎没有参考意义，必须看P95、P99分位值——因为最慢的那5%用户往往决定了口碑。同时要把客户端指标与服务端资源指标（CPU、内存、GC频率、连接池占用、慢SQL）对齐时间轴，才能定位真正的瓶颈层。 还有一个常被忽略的维度是稳定性测试。让系统在中等负载下连续运行24到72小时，观察内存是否缓慢泄漏、连接数是否只增不减、日志是否堆积撑爆磁盘。这类问题在短时压测中完全暴露不出来，却是生产环境凌晨告警的常客。 总结一句话：性能测试的产出不应该是一份漂亮的TPS数字，而应该是一份明确的容量结论和瓶颈清单——当前架构支撑多少并发、扩容哪一层收益最大、什么阈值需要触发告警。能回答这三问，性能测试才算真正落了地。