社区团购小程序：我踩过的坑和真话

去年帮一个做生鲜的朋友搭社区团购小程序，从立项到上线折腾了快两个月。中间踩的坑不少，今天把过程里真实的东西写出来，给想做这块的朋友省点时间。

先说清楚：社区团购小程序到底在解决什么

很多人一上来就问“做个社区团购多少钱”，其实先得想明白业务模型。社区团购的核心链路就四步：团长开团 → 用户下单 → 平台汇总采购 → 次日自提。小程序要做的就是把这四步串起来，别想得太复杂。

我朋友那个盘子很小，三个小区、五个团长，日单量峰值也就两百多单。这种体量，真没必要上什么微服务、分布式，一套微信小程序加云开发就够了。

技术选型：为什么我选了云开发

独立开发者做这类项目，最怕的是运维。服务器、数据库、对象存储、定时任务，一套配下来光环境就能耗掉一周。所以我直接用了云开发：

• 数据库用云数据库，商品、订单、团长、自提点四张核心表
• 图片走云存储，商品图压缩到 200KB 以内，加载快
• 下单、库存扣减用云函数，避免前端直接改库存
• 每日截单用定时触发器，晚上十点自动汇总订单

成本上，初期一个月几十块，比租台云服务器还便宜。当然，如果你预期日单量上千，还是老老实实上自建后端，云开发的冷启动和并发限制会咬人。

几个真正卡住我的问题

1. 库存并发扣减

社区团购的商品经常是限量秒杀，比如“今日特价鸡蛋 50 份”。最开始我在前端判断库存，结果两个用户同时下单，超卖了。后来改成云函数里用事务处理：

const db = cloud.database()
const _ = db.command

exports.main = async (event) => {
  const { goodsId, count } = event
  return await db.runTransaction(async transaction => {
    const goods = await transaction.collection('goods').doc(goodsId).get()
    if (goods.data.stock < count) {
      throw new Error('库存不足')
    }
    await transaction.collection('goods').doc(goodsId).update({
      data: { stock: _.inc(-count) }
    })
    return { ok: true }
  })
}

这段代码不复杂，但当时不知道云开发有事务，绕了不少弯路。

2. 团长分佣算不清

团长佣金按订单金额的百分比算，还要区分自提和配送。最开始我图省事，在前端算完存进去，结果退款、改单之后数据全乱。后来改成订单状态变更时由云函数统一重算，前端只展示。这个教训很值钱：凡是涉及钱的逻辑，一律放后端。

3. 自提核销体验

用户到自提点，团长要核销。我一开始做了扫码核销，结果大爷大妈不会用。后来改成团长在后台输入订单尾号后四位，一键核销，投诉立马少了。做社区生意，用户年龄层摆在那，交互越简单越好。

关于费用，说点实在的

经常有人问我社区团购小程序开发费用。我的答案是：看你要什么。

• 纯模板套壳，几千块能搞定，但团长分佣、多自提点这些基本要二次开发
• 定制开发，功能完整的一套，独立开发者报价大概一到三万，外包公司翻倍很正常
• 云开发方案能省掉服务器和运维成本，长期看更划算

别信那种“三千块做个完整社区团购”的广告，后面加功能、改 bug 的钱够你再做一套。

上线之后才明白的事

技术做完只是开始。真正决定这个社区团购小程序能不能跑起来的，是团长。我们上线第一个月，五个团长里只有两个认真在群里推，另外三个基本躺平。后来朋友调整了分佣阶梯，加上每周给团长发点小福利，活跃度才起来。

所以如果你也在做这块，我的建议是：技术方案选轻的，把精力留给运营。小程序是工具，私域流量和团长关系才是这门生意的命根子。

代码可以慢慢优化，人跑了就真没了。