宁波商城小程序大促前服务器扩容与压测清单

大促当天小程序打不开、下单转圈、支付回调失败，这类事故八成不是代码写错了，而是容量没准备够、压测没做到位。宁波不少做商城小程序的商家，平时日订单几百单跑得很稳，一到大促流量翻几倍，数据库连接池、图片带宽、支付回调队列先后告急。提前两周做一次认真的扩容和压测，比事后道歉有用得多。

先算容量，再谈扩容

扩容不是把服务器配置往上加一档就完事。你需要先回答三个问题：大促预计峰值多少人同时在线、峰值每秒多少笔下单请求、图片和视频的带宽峰值是多少。这三个数一般按日常峰值的倍数来估，比如一家做社区团购的店，日常晚高峰同时在线两百人，大促按五到八倍准备，留出余量。

• 并发用户数：决定应用服务器和数据库连接数
• 下单峰值 TPS：决定订单服务和库存扣减的承载能力
• 静态资源带宽：商品图、首页 Banner 集中加载，最容易先被打满

把这三个数写进一张表，和开发方逐项确认，比口头说“大促帮我扩一下”靠谱得多。

压测要压真实链路，不是压首页

很多团队压测只压首页打开速度，结果大促当天首页没事，下单接口先挂了。真实链路至少覆盖：登录、浏览商品、加购、下单、支付回调、订单查询。其中支付回调和库存扣减是最容易被忽略的两环，因为它们依赖第三方和数据库事务，压测时往往没模拟到位。

1. 用接近真实的用户路径压测，不要只发单接口请求
2. 压测数据要和线上数据量级接近，商品数、订单表数据量太少会失真
3. 观察数据库慢查询和连接池等待时间，而不是只看成功率
4. 压测后留出至少一周做调优和回归，不要压完就上线

压测的价值不是证明系统能扛住，而是提前找到第一个会断的地方。

大促前容易被忽略的四个盲区

服务器扩容清单里，硬件之外还有几件事经常被漏掉。第一，公众号菜单、小程序码、短信里的短链是否指向最新活动页，大促前改过页面路径的要逐一回归。第二，图片和视频是否走了 CDN，如果没有，扩容服务器也救不了带宽。第三，支付回调地址的证书是否在有效期内，过期会导致回调失败、订单状态卡住。第四，客服和售后入口是否承压，订单暴涨时咨询量同步上涨，人工回复不过来会直接拉低评分。

• 检查所有对外入口链接和二维码是否有效
• 静态资源确认走 CDN，并提前预热活动页
• 证书、域名解析、回调白名单逐项核对
• 准备客服话术和自动回复，分流常见问题

给宁波商家的执行时间表

以购物节为例，倒推两周比较稳妥。大促前十四天完成容量预估和扩容方案确认；前十天下单扩容、配置监控告警；前七天做第一轮全链路压测；前五天根据压测结果调优并复测；前三天锁定版本，只做配置变更不做代码大改；前一天做一次小流量回归和值班排班。这个节奏对慈溪做商城小程序定制的商家同样适用，定制项目越复杂，越要提前。

如果你不确定自己的小程序该按什么量级准备，可以先把日常峰值数据拉出来，和开发方对一遍，再决定扩容幅度。大促拼的不是谁服务器贵，而是谁把清单执行得细。