系统上线前为什么建议做压力测试？

功能测试只能保证"系统能不能跑"，压力测试要回答的是"在真实业务量和高峰场景下能不能稳"。涉及设备接入、交易、活动、内容上传的系统，没做过压测就上线，往往等用户冲进来才发现哪里崩。滚水科技在交付前会针对这类系统单独排一段时间做压测。

压测帮我们回答几个上线前必须心里有数的问题：

1. 当前架构的承载上限是多少——能稳定支持多少并发用户、多少 QPS。这个数字直接决定要不要扩容、要不要重新设计架构。
2. 瓶颈在哪一层——数据库、缓存、带宽、应用服务器、第三方依赖，到底是哪个组件先撑不住。瓶颈不同，优化方向完全不一样。
3. 是否会雪崩——一个服务挂掉之后，是不是会拖垮其他服务。这个比单点性能更要命。
4. 错误模式可不可控——压到极限的时候，系统是平滑降级、合理拒绝，还是直接 500 一片。
5. 从故障到恢复需要多久——服务器重启、缓存预热、连接池重建，每一步耗时累加起来，决定真实的"恢复时间"。

这些问题如果到上线后才暴露，代价就高了。我们做 新能源智能充换电 这类设备并发上报的系统时，特别会模拟"几千台终端同时心跳 + 高频指令"的场景，因为单接口压测看着没问题，但叠加 MQTT 长连接、设备状态查询、消息推送一起跑，瓶颈才会暴露出来。

哪些项目特别建议在上线前做压测：

• 设备接入或 IoT 类，并发设备数 > 1000
• 涉及秒杀、抢购、限时活动的电商或票务
• 内容/视频上传量大的社交、UGC、直播类
• 涉及实时计算（推荐、风控、计费）的交易系统
• 政企或核心管理类，有明确并发指标要求的

哪些不一定要做：

• 内部使用的轻量管理后台，几十人规模
• 工具型 App，并发自然限制在用户操作频率
• 还在 PMF 验证阶段，先看业务能不能跑通

压测的成本不算太高，通常 2–5 人天能出一份完整的报告，包含瓶颈定位、扩容建议、关键指标基线。相比上线后救火，这笔投入很划算。