做性能压测前，小程序开发公司要先拿到团长开团时间表和截单时间。社区团购的下单集中在每晚 20:45 到 21:15 这段开团到截单的窗口，一个 300 到 500 户的小区社群，会在 15 分钟内涌进 800 到 1500 笔加购请求，瞬时并发是白天闲时的 8 到 12 倍。输入就是这份团期排程和近 30 天真实订单样本；动作是把 24 小时拆成 96 个 15 分钟格，标出每个格的预估 QPS；产出是一张峰值流量曲线，峰值通常落在 21:00 前后。常见失败点是直接拿全天平均订单除 86400 算容量，结果按闲时配的容器，一到截单就雪崩。这一步的产出必须交给后续每一步当基准线，峰值 QPS 建议按团期历史最高值的 1.5 倍预留。

第二步：列出核心链路，给每条链标注读写权重

输入是小程序的功能清单和小程序开发公司画的接口时序图。动作是按“浏览开团页—加购—提交订单—支付回调—库存扣减—团长端推单”六条链路逐一过，标注每条是读多写少还是写多读少。产出是一张场景权重表，生鲜团购里写多的是库存扣减和支付回调，读多的是商品详情和团长排行。常见失败点是漏掉支付回调这条异步链路，压测只跑同步下单，上线后微信支付异步通知一拥进来，库存服务被打挂。这一步要把回调链路单独列一条，权重不低于总流量的 20%，因为每笔成功支付都会触发一次回调补偿。

第三步：建影子库造脱敏数据，绝不直接打生产

输入是脱敏后的真实订单样本，字段要包含 SKU 编码、规格、单价、团长 ID、提货点。动作是由小程序开发公司在预发环境克隆一份影子表，把库存数量按 1:1 还原到压测库，订单表用假用户 ID 灌入。产出是一套能跑完整下单到支付闭环的影子环境。常见失败点是图省事直接对生产库压测，压完一批库存被扣成负数，第二天真实开团超卖赔钱。这一步要求影子库与生产库同构、同索引，数据量至少覆盖一个城市 2000 到 5000 个团长的体量，否则压出来的拐点没有参考价值。

第四步：梯度加压，盯住 TPS 拐点和错误率

输入是上一步的影子环境和峰值曲线。动作是用压测平台从 200 虚拟用户起步，按 200、500、1000、2000、4000、6000 六档逐级加压，每档稳定跑 10 分钟再升下一档，下单接口必须带真实库存扣减。产出是每档的 TPS、P99 响应时间和错误率曲线。常见失败点是一口气打到 6000 并发，只看到系统挂了，却找不到拐点到底在哪一档，没法反推该配多少资源。这一步要记录下来：当虚拟用户到哪一档时，P99 响应时间突破 800 毫秒或错误率突破 0.5%，那里就是容量上限的临界点。

第五步：按拐点锁容量，应用层和数据库一起扩

输入是第四步记下的拐点档位和对应 TPS。动作是让小程序开发公司反推容器副本数、Redis 连接池和数据库只读副本。举例，若拐点在 4000 并发、实测单副本 8C16G 扛 600 TPS，则峰值 6000 QPS 需要 10 到 12 个副本；Redis 连接池开到 300 到 400 避免抢连；MySQL 主库写、挂 2 个只读副本分流商品查询。产出是一份写清副本数、连接池、副本关系的容量预案。常见失败点是只横向加应用容器，不调数据库和缓存，结果应用层扩容后请求全堵在单库上，拐点没动。预案要明确高峰期自动扩副本、低峰缩容的触发阈值。

第六步：按峰值 1.2 倍跑稳定性，卡死验收线

输入是容量预案和影子环境。动作是在预发按峰值 QPS 的 1.2 倍持续压 30 分钟，全程监控库存超卖率、下单成功率、回调延迟。验收标准就三条：下单接口成功率不低于 99.95%，库存超卖率低于 0.05%，P99 响应时间稳定小于 800 毫秒且无持续上涨。常见失败点是稳定性只跑 5 分钟就验收，没暴露连接池耗尽和内存缓慢泄漏。达到这三条，小程序开发公司才算把生鲜团购的容量规划交付清楚，可以排上线窗口。