生鲜小程序定制：从需求到上线的实战拆解

生鲜这个品类，做小程序和做别的电商不太一样。标品电商可以一套模板打天下，生鲜不行——称重、分拣、时段配送、损耗控制，每一个环节都会反过来影响前端交互。我去年完整交付过一个社区生鲜项目，从需求梳理到上线跑了三个月，中间踩的坑不少。这篇文章把定制流程拆开讲，给准备做生鲜小程序的同行一点参考。

先想清楚：哪些是标品，哪些必须定制

很多甲方一上来就说“我要一个像某某买菜那样的小程序”。这句话本身没错，但容易让人误以为整个项目都要从零写。实际上生鲜小程序可以拆成两层：

• 通用层：商品列表、购物车、订单、支付、优惠券、个人中心。这部分用成熟框架或云开发模板能覆盖七八成，没必要重复造轮子。
• 定制层：称重商品的价格计算、按配送时段切分库存、临期折扣、团长分佣、自提点核销。这些才是生鲜的命门，也是定制费用的主要来源。

我的做法是先列一张功能矩阵表，把每个功能标上“模板可满足 / 需改造 / 必须自研”。这张表直接决定了报价和工期，也能避免后期扯皮。甲方看到你分得清轻重，信任感会强很多。

称重商品是第一个硬骨头

标品是“一件 9.9 元”，生鲜是“一斤 3.8 元，实际称了 1.26 斤”。这中间的差价怎么处理，直接影响下单流程。常见方案有三种：

1. 下单时按预估价支付，拣货后称重，多退少补。
2. 下单时只锁定库存，拣货后生成待支付尾款。
3. 整件售卖，提前分装好固定重量。

第一种体验最好但退款逻辑复杂，第二种资金流清晰但转化率低，第三种最省事但损耗高。我最终选了第一种，核心是把“预估”和“实付”在订单模型里拆成两个字段：

{
  orderNo: "SG20240512001",
  items: [
    {
      skuId: "VEG-0231",
      name: "本地小油菜",
      unit: "斤",
      estimatedWeight: 1.0,
      actualWeight: 1.26,
      unitPrice: 3.8,
      estimatedAmount: 3.80,
      actualAmount: 4.79
    }
  ],
  estimatedTotal: 3.80,
  actualTotal: 4.79,
  settleStatus: "pending"
}

拣货完成后调用称重接口回写 actualWeight，再触发一次差额结算。差额为正走补款，为负走原路退款。这里要注意微信支付的退款有频率限制，别每单都单独退，最好按日批量处理。

配送时段与库存的绑定

生鲜的库存不是“有多少件”，而是“某个时段能送多少单”。用户下单时选的不是商品，是“明天 18:00-20:00 这一档还有没有运力”。所以库存表要按 skuId + deliverySlot 建联合唯一键，扣减时用数据库的原子操作，不能先查后改：

UPDATE slot_stock
SET remain = remain - 1
WHERE sku_id = ? AND slot_id = ? AND remain > 0;

影响行数为 0 就说明这一档满了，前端要立刻把该时段置灰。这个细节看着小，但高峰期并发下单时，先查后改一定会超卖，我见过不止一个项目栽在这。

临期折扣别做成定时任务

很多教程建议用定时任务扫表改价，实际跑起来问题不少：任务延迟导致价格不准、改价瞬间大量用户看到新旧两个价格。更稳的做法是价格在读取时动态计算——商品表只存原价和保质期，展示层根据当前时间和入库时间算折扣系数。这样既没有延迟，也方便运营随时调规则。

动态计算会增加一点查询开销，可以在 Redis 里缓存计算结果，按商品维度设短 TTL，命中率很高。

自提点核销与团长分佣

社区生鲜绕不开自提。核销环节我建议直接做在小程序里，用 wx.scanCode 扫订单码，后端校验订单状态和自提点归属，避免团长跨点核销。分佣则要单独建流水表，按订单完成时间而非支付时间结算，因为生鲜退货率高，支付就分佣容易产生坏账。

关于费用和周期的实话

一个功能完整的生鲜小程序，定制开发大概在 4 到 8 万之间，差异主要来自是否需要对接第三方 ERP、是否需要多门店、是否要做直播。工期通常 10 到 14 周。如果有人报价两万还承诺一个月上线，多半是拿模板改的，称重和时段库存这两块大概率是糊弄过去的。

另外提醒一句：上线前一定要用真实称重设备跑一遍全流程，电子秤的串口协议、小数位精度、单位换算，这些在模拟环境里测不出来，上线后才发现就要返工。生鲜小程序的门槛不在页面好不好看，而在这些脏活累活有没有做扎实。