别一开始就喊高并发，先确认真实峰值和瓶颈

关键判断一览

把“同时很多人”变成具体访问模型

先说明活动中哪些操作会集中发生：看页面、查库存、提交订单还是生成报表。用户数不能直接等同于每秒请求量。

给出目标数据量、持续时间、突发程度与可接受的响应体验，记录当前延迟、错误率和资源占用。测试模型应接近日常与峰值任务组合。

• 区分读多写少与交易写入密集的场景。
• 先采集接口、数据库和外部服务耗时，再讨论扩容。

优化要对应可观察的瓶颈

慢查询、连接耗尽、重复计算、外部接口限流和资源不足需要不同处理。增加缓存前先判断数据能否过期，不能把余额或库存一致性问题藏进缓存。

队列可以缓解瞬时压力，但用户需要知道任务是已完成还是待处理。超时重试同样要避免重复创建订单或重复扣减。

• 一次只验证一个主要假设，比较修改前后指标。
• 检查优化是否增加数据延迟、费用或恢复复杂度。

压测验收还要看恢复与降级

达到某个峰值只是结果的一部分，还要验证压力下降后队列能否消化、连接能否恢复、异常数据是否可校正。

在隔离环境测试关键链路，不使用真实付费或对外通知操作做无控制压测。上线采用受控流量，并准备撤回配置或版本的方式。

• 同时记录吞吐、延迟分位数、错误率与数据正确性。
• 约定超载时哪些功能排队、限流或暂停。