生鲜配送小程序开发实战指南

生鲜配送是过去两年小程序创业里最卷也最实在的赛道之一。客单价不高、复购强、履约链路短，但真正做起来会发现：难点不在前端页面，而在库存、分拣、配送时段和退款这四件事上。这篇文章结合我做过的一个日单量 3000+ 的生鲜小程序项目，聊聊开发中的关键取舍。

一、先想清楚：你的模式决定架构

生鲜配送小程序大致分三类，架构差异很大：

• 前置仓模式：覆盖 3 公里，30 分钟送达，库存实时扣减，对并发要求高。
• 次日达模式：今晚下单明早送，按批次分拣，库存可以按日结。
• 社区团购模式：以团长为单位集单，履约成本最低，但分佣逻辑复杂。

我建议早期不要三种都做。选一种，把下单到签收的主链路跑顺，比堆功能重要得多。

二、商品与库存：别用 SKU 硬扛

生鲜的商品模型和普通电商不一样。同一个「西红柿」有多个规格（500g / 1kg / 家庭装），还有称重商品和标品之分。我的做法是：

• 商品表（product）只存展示信息：名称、主图、详情、类目。
• 规格表（sku）存价格、库存、单位、是否称重。
• 称重商品下单时不扣具体库存，而是下单后由分拣员录入实际重量，再补差价。

// 下单时库存预占，避免超卖
async function lockStock(skuId, qty) {
  const res = await db.collection('sku').where({
    _id: skuId,
    stock: _.gte(qty)
  }).update({
    data: { stock: _.inc(-qty), locked: _.inc(qty) }
  });
  if (res.stats.updated === 0) {
    throw new Error('库存不足');
  }
}

关键点：下单即锁库存，15 分钟未支付自动释放。这一步不做，活动一上就超卖，退款能把你客服打爆。

三、配送时段：生鲜的命门

用户最在意的不是「多久送到」，而是「我几点能收到」。所以下单页第一屏应该是配送时段选择，而不是优惠券。

实现上，把时段做成可配置的：

• 每个时段有容量上限（比如 30 单/时段）。
• 下单时校验剩余容量，满了就置灰。
• 时段和配送员排班绑定，避免出现没人送的时段。

// 时段容量校验
const slot = await db.collection('slots').doc(slotId).get();
if (slot.data.used >= slot.data.capacity) {
  return { code: 400, msg: '该时段已约满，请选择其他时段' };
}
await db.collection('slots').doc(slotId).update({
  data: { used: _.inc(1) }
});

四、分拣与配送：后台比前台难做

很多开发者把精力全放在 C 端页面，结果后台一塌糊涂。生鲜后台至少要三块：

1. 分拣单：按订单聚合商品，生成拣货清单，支持打印。
2. 配送单：按配送员和时段聚合，生成路线顺序。
3. 异常处理：缺货、漏发、破损，都要能一键退款或补发。

分拣单的聚合逻辑是核心：把同一时段所有订单的商品按 SKU 汇总，分拣员一次拣完再按订单拆分，效率能提升 3 倍以上。

五、退款与售后：别让用户等

生鲜退款有两个特点：金额小、频率高。如果每单都人工审核，成本会吃掉利润。我的建议是：

• 缺货退款：系统自动原路退回，不需要审核。
• 质量问题：用户上传照片，客服 2 小时内处理。
• 称重差价：多退少补，自动计算。

生鲜的复购靠的不是补贴，而是「这次没出问题」。退款速度直接决定用户下次还来不来。

六、性能与成本控制

小程序端要注意两点：图片和列表。生鲜商品图多，一定要用 CDN + WebP，列表页做虚拟滚动。后端如果是云开发，注意数据库读次数，商品列表做 5 分钟缓存，能省不少钱。

另外，不要把库存扣减放在前端。所有涉及库存、金额的操作，必须走云函数或服务端接口，前端只负责展示。

七、上线后的迭代节奏

我的经验是：第一版只做「浏览-下单-支付-配送-签收」，不要做会员、积分、拼团。上线两周看数据，重点看三个指标：下单转化率、履约准时率、退款率。哪个差补哪个，比拍脑袋加功能有效得多。

生鲜配送小程序不是技术炫技的战场，而是细节和稳定性的比拼。把库存、时段、分拣、退款这四件事做扎实，基本就能跑赢大部分同行。