去年双十一前一周，一个做日用品的客户搞预售，晚上八点开抢，两分钟后订单页面集体转圈，客服电话被打爆。事后排查，服务器是按日常流量配的，峰值一来直接趴窝。商城小程序开发的性能账，平时一点看不出来，活动当天全是利息。
先估清楚你的峰值有多少人
并发不是按粉丝数算的。有个粗糙但实用的参考：活动开始前一小时的进入量，大概是平时同时在线的十到二十倍。社群五千人的店，开抢瞬间涌进来七八百人很正常。把预估峰值告诉开发方，让他们按这个数配服务器、定压测目标，别拍脑袋说差不多就行。还有个容易忽略的点：活动预热期的短信、社群推送会把流量精确地压到同一个时间点，推送文案里少写一个准点，峰值就能平掉一截。客服和运营也要参与压测预案，真出状况时谁发安抚话术、谁手工补单，提前分工好。
压测不是点点页面那么简单
很多项目所谓的压测，就是几个人同时刷首页，那测不出任何问题：
- 下单链路要从选品走到支付成功，整条跑，不是只刷浏览页
- 库存扣减在并发下会不会超卖，这是最容易出事也最难补救的地方
- 数据库查询、图片加载在高峰期的响应时长，超过三秒人就开始流失
正规做法是用工具模拟几百个虚拟用户同时下单，看哪一环先崩，修完再压。压测环境尽量贴近生产配置，本地小服务器测出来的数据没有参考意义。压测报告要留档，上线前跑一轮，每次大活动前再跑一轮，数据对比着看。
真要做秒杀，架构得单独设计
秒杀是并发的极端场景：库存要进缓存、请求要排队、订单要异步处理，一套组合拳下来开发量不小，报价自然也高。商品数量少、预算有限的，可以改用预售或者分时段开抢，把峰值削平，体验未必差，成本却低不少。硬要上秒杀的，就按秒杀的架构给商城小程序开发立项做预算，别用普通商城的价格去砍秒杀的方案，砍到最后双方都难受。
建议两条：活动排期定下来就提前两周做压测，留足调整和复测的时间；服务器选可以临时升配的云方案，大促前升级、过后降回来，钱花在刀刃上。比格网络给商城项目交付前，压测报告是标配验收项，翻过车的坑，不该让新客户再踩一遍。
