生鲜小程序开发实战避坑

先把「生鲜」两个字拆开看

很多人一上来就问：生鲜小程序开发怎么做，用什么框架、找谁做、多少钱。这个问题问得太早了。生鲜这个品类跟别的电商不一样，它的坑不在代码里，在业务里。我做过三个生鲜类的小程序，两个死在了库存同步上，一个活下来是因为把配送范围砍到了三个小区。所以先别急着写代码，先想清楚三件事：你的货从哪来、送到哪、坏了谁赔。

这三件事决定了技术选型。如果只是社区团购，团长自提，那库存和配送逻辑可以极简；如果是前置仓加即时达，那你要面对的是分钟级的库存扣减和骑手调度，复杂度直接翻倍。我见过太多人拿一个通用商城模板改吧改吧就上线，结果第一天就因为超卖被投诉到封号。

技术选型：别为了炫技给自己挖坑

原生还是跨端

生鲜小程序的交互其实不复杂——列表、详情、购物车、下单、订单状态。这种场景我强烈建议直接用微信原生，配合云开发。理由很实在：生鲜的迭代速度快，你今天加个「今日特价」板块，明天改个「满减凑单」，原生开发改起来最直接，调试也最省心。跨端框架在生鲜这种重运营、轻交互的项目里，省下的那点多端适配成本，还不够你填坑的。

云开发到底够不够用

够，但有边界。云开发的数据库和云函数对于日订单几百到两三千的量级完全扛得住，而且省掉了服务器运维和备案的麻烦，对独立开发者特别友好。但有两个地方要注意：

• 库存扣减不能用客户端直接写。一定要走云函数，并且在云函数里用原子操作或者事务，否则并发下单必然超卖。
• 图片别直接传原图。生鲜的图片多，详情页动辄七八张，云存储的流量费会咬人。上传时压缩到 750px 宽，用 WebP，能省一半以上。

// 云函数里做库存扣减，关键是条件更新
const db = cloud.database()
const _ = db.command

exports.main = async (event) => {
  const { goodsId, count } = event
  // 只有库存足够时才更新，返回值告诉我们成没成
  const res = await db.collection('goods')
    .where({ _id: goodsId, stock: _.gte(count) })
    .update({ data: { stock: _.inc(-count) } })
  if (res.stats.updated === 0) {
    return { ok: false, msg: '库存不足' }
  }
  return { ok: true }
}

注意 where 里带了 stock: _.gte(count)，这一步是防超卖的核心。很多教程只写 update 不写条件，线上必炸。

生鲜特有的几个硬骨头

规格和称重

生鲜的商品模型比普通电商麻烦。一斤苹果可能按份卖，也可能按重量卖，还可能「约 500g，实际 480-520g」。我的做法是把「份」作为最小销售单元，重量只作为展示信息，下单时锁定份数，实际称重差异在履约环节做补退。这样前端逻辑干净，后端也不会因为浮点数重量算出一堆小数。

配送时段和截单

生鲜几乎都有「今日下单、次日达」或者「上午下单、下午达」的规则。这个必须做成配置，不能写死。用一张 delivery_slots 表存时段、截单时间、容量，下单时校验并占用容量。别小看容量控制，一个时段接太多单，配送员跑不过来，差评就来了。

损耗和退款

生鲜退款率高是常态，叶菜、水果尤其。退款流程要做得快，最好支持「拍照上传 + 一键退款」，金额小的直接自动通过。这不是技术问题，是成本核算问题——为了几块钱的菜跟用户扯皮，人工成本比菜贵。

上线前必须压一遍的几件事

• 购物车在弱网下的表现。生鲜用户经常在电梯里、菜市场里下单，网络抖动是常态，本地缓存要兜住。
• 首页图片的懒加载和骨架屏。生鲜首页图多，首屏白屏两秒，用户就走了。
• 订单列表的分页。别一次拉全部订单，用户订单多了会卡。
• 订阅消息的模板要提前申请，生鲜的「订单状态变更」「配送提醒」都靠它，审核要时间。

说句实在话：生鲜小程序开发的技术难度中等，难的是业务闭环。代码写得再漂亮，库存对不上、配送送不到，一样是零。

关于成本和人力

如果自己写，云开发加一个前端，一个人两三周能出可用版本，成本主要是时间和一点云资源费。如果找外包，一定要在合同里写清楚库存并发、退款流程、配送时段这三块的验收标准，不然交付的时候你会发现模板里根本没有这些。生鲜这行，省下的开发费往往会在运营第一个月以差评的形式还回来。

最后一句：先跑通一个小区，再谈扩张。小程序只是工具，供应链才是生鲜的命。