大促当天的系统崩溃，损失的不只是那几小时的订单，还有用户信任与平台评分。而绝大多数事故，都可以在大促前的压测里提前暴露。这份压测清单，按时间线组织。
压测前的准备（T-30 天）
- 定目标。根据活动力度预估峰值 QPS（参考历史大促数据 × 增长系数 × 1.5 倍冗余），明确“系统必须扛住什么”。
- 摸清家底。梳理全链路依赖：网关、应用、缓存、数据库、第三方接口（支付、物流、短信）——任何一个短板都是全局瓶颈。
压测场景设计（T-20 天）
- 核心链路必测。浏览、加购、下单、支付、查询库存——按真实用户行为比例混合建模，纯接口压测没有意义。
- 异常场景要测。缓存击穿、热点商品、支付回调洪峰、第三方接口超时——事故往往发生在这些边角。
- 逐步加压到极限。不只测“目标容量”，更要测出“极限容量”和“崩坏方式”，才知道预案的边界。
执行与预案（T-10 天）
生产环境影子库压测（数据隔离），真实流量回放；每个瓶颈给出处理方案（扩容、限流、降级、优化）并复测；限流与降级预案演练到“开关一拉就生效”；值班表与应急通讯树确认。大促稳定性是“预案的艺术”——压测的目的不是证明系统没问题，而是确认问题发生时你知道怎么办。