生鲜App开发避坑实录

去年帮一个做了八年水果批发的老板做生鲜App，需求聊了两小时，他反复强调一句话："我这行最怕的不是没人下单，是下单了送不出去。"这句话基本决定了整个项目的技术走向。生鲜App和普通电商App看着像，骨子里差得远，下面按实际开发顺序说几个关键点。

先想清楚履约模型，再动手写代码

生鲜的SKU有重量、有保质期、有损耗，这三样东西会渗透到数据模型的每一层。常见的有三种模式：

• 前置仓：每个仓覆盖3公里，库存按仓隔离，适合自营配送，但仓的库存同步是个大麻烦；
• 门店自提：库存直接挂在门店上，用户下单后到店核销，开发量最小；
• 产地直发：SKU少、批量大，按箱卖，库存压力小但时效差。

很多外包团队上来就套通用商城模板，结果做到一半发现"按斤卖"的商品没法拆单、称重后价格会变、缺货要支持替换，改起来比重写还贵。我的建议是：把"称重商品"和"标准商品"在数据库里就分成两种类型，字段和流程分开设计，别硬塞进一张表。

商品模型：重量和价格必须解耦

生鲜最典型的场景是用户下单一斤排骨，实际称出来1.08斤。如果下单时就把价格算死，后面要么补差价要么亏钱。比较稳妥的做法是下单时按预估重量冻结金额，拣货称重后生成"实际结算单"，再走多退少补。核心表结构大致是：

order_item
  sku_id
  estimate_weight   -- 下单预估重量
  actual_weight     -- 拣货后回填
  unit_price        -- 每斤单价
  settle_amount     -- 实际结算金额
  weight_status     -- pending / confirmed

支付环节也要配合，冻结金额用预授权或者先付后补，别在支付回调里直接改订单金额，很容易和支付平台对不上账。这块逻辑最好单独抽一个结算服务，和订单主流程解耦。

库存和损耗：别用电商那套扣减逻辑

普通电商库存是"下单即扣、取消即回"，生鲜不行。一批菜到了仓里，今天卖不掉明天就蔫，损耗是每天都在发生的。实际做法是：

• 库存按批次管理，记录入库时间，先进先出；
• 每天定时任务跑一遍临期批次，自动打折或者下架；
• 下单只做"预占"，拣货完成才真正扣减，超时未拣货自动释放；
• 损耗单独记流水，不混进销售数据，否则毛利永远算不准。

这套逻辑用云开发的定时触发器就能跑，不需要额外买服务器。库存预占建议用Redis的原子操作，别在数据库里用"查一下再减"，并发上来必超卖。

配送调度的坑比想象中多

生鲜订单有时效窗口，比如"今日18点前送达"。调度要解决的是：订单怎么分给骑手、路线怎么排、超时怎么预警。小团队没必要自研调度算法，先把这几件事做扎实：

• 按配送区域做订单池，骑手接单前先看自己区域；
• 订单状态机要完整：待接单→已接单→已取货→配送中→已送达，每一步都要有超时兜底；
• 用户端的位置展示用轮询就够，别一上来就上WebSocket，成本高收益低；
• 异常订单（拒收、地址错误）要有独立流程，别和正常订单混在一起。

说个真实教训：项目上线第一周，骑手端没做"离线缓存"，进电梯断网后订单状态卡住，用户以为没发货打电话投诉。后来加了本地队列重试才解决。生鲜场景的网络环境比办公室差得多，客户端必须假设随时会断网。

客户端性能：图片和列表是重灾区

生鲜App首页全是商品图，一个列表几十张高清图，低端机直接卡死。几个必做的优化：

• 图片统一走CDN，按尺寸出多套图，列表用缩略图，详情页再加载大图；
• 列表用虚拟滚动或者分页加载，别一次性渲染几百个商品卡片；
• 骨架屏比loading转圈体验好，生鲜用户等三秒就跑了；
• 下单页的表单校验放本地，别每次输入都请求接口。

如果是小程序形态，包体积控制在2M以内，主包只放首页和下单流程，其余分包。这块在审核和首屏速度上差别很明显。

最后说成本

生鲜App的开发成本主要不在页面数量，而在履约逻辑。一个能跑通"下单-称重-结算-配送"闭环的MVP，自己开发大概两到三个月，外包报价通常比普通商城高30%以上，因为库存和结算模块的复杂度摆在那。建议第一版砍掉会员体系、积分、复杂营销，把履约跑顺，等单量稳定了再补运营功能。生鲜这行，送得出去比卖得便宜重要得多。