接到亿家旺生鲜这个项目时，对方给我的需求描述其实特别朴素：能让门店在微信上接单，让周边三公里的居民在小程序里买菜，最好别让我每天用手抄订单。听上去不复杂，但真正动手，才发现生鲜订单远比想象中麻烦——商品的保质期、库存的两级分布、配送时段的选择、支付后的自动冲正，随便哪一环没做好，都可能让门店在高峰期直接炸锅。这篇文章就结合这个“亿家旺生鲜云订单零售系统”的设计和实现过程，聊聊我在这个项目里的真实决策：为什么选微信生态，订单状态机怎么画，库存怎么锁才不会超卖，支付回调怎么做到幂等，以及那些让我半夜起来改代码的坑。
1. 项目背景与核心问题：为什么是这个切入点
1.1 生鲜订单的不可预测性与时效性
生鲜零售和普通标品零售最大的区别，就是“鲜”字带来的两个钢印：库存变数大，时效压力大。蔬菜、水果、肉禽蛋、日配品的保质期通常只有几天，甚至当天就要卖完。传统线下门店损耗率一般控制在10%以内就已经算优秀，而一旦把订单搬到线上，等于把“碰运气”变成了“系统性问题”。用户下单时看着库存有货，等到拣货时可能已经变质、被其他订单先拿走，或者配送途中化掉，这都需要在系统设计阶段就给出预期管理。
我在项目调研时统计过，一个中等规模生鲜门店每天SKU能到800到1200个，其中叶菜、豆制品、海鲜这类短保商品占据大概四成。每逢下雨天，蔬菜订单会翻倍，水产偶尔爆单；而晴天高温时，奶油、奶制品订单又会集中在上午。这种波动根本不是人为手工登记能跟上的。原来门店用微信群接龙，顾客在群里发“五花肉2斤、菠菜1把”，店员边看消息边手写单子，高峰期消息一刷屏，漏单错单是家常便饭。更关键的在于，订单和库存完全割裂，群里的单子没有扣减门店库存，顾客到店自提时发现没货，体验直接崩塌。
所以这个系统的第一优先级不是好看的前端，而是把“订单”和“库存”这两件事变成系统闭环。用户看到的是“可售”，门店看的是“待拣货”，后台看的是“已锁定”，每个数字必须能对得上。后面我会详细讲这个闭环怎么落地，但先记住一句话：生鲜订单系统本质上是一套时刻在变化的资源调度系统，它不是企业进销存，也不是简单电商，而是两者的结合。
1.2 微信生态带来的低门槛和支付闭环
为什么选择微信生态，而不是老老实实做一个独立App？这个问题我当时跟技术合伙人反复讨论过。结论很实际：我们的目标用户是门店周边三公里的居民，他们不太可能为了买一把菜专门下载一个App，但微信是天天要打开的。小程序带着天然的轻量优势，扫码即用，不需要安装，不占手机内存，对中老年用户尤其友好。
其次，微信生态的支付闭环是现成的：用户在小程序里下单，直接拉起微信支付，支付完成回调我们需要处理；退款也能通过微信支付原路退回，财务对账相对清晰。加上订阅消息可以推送订单状态变化，公众号可以把门店活动和优惠券触达给用户，社群里的分享卡片也能直接跳到小程序。这一整套东西，如果自己做，光支付合规和推送通道就要折腾很久。
还有一个很重要的点：微信生态里的“关系链”对生鲜零售是隐藏红利。很多用户住在门店附近，他们会在业主群里转发小程序商品卡片，这种基于微信信任链的传播转化率远高于广告投放。我们在系统里专门留了分销员和分享追踪功能，订单卡片落地页会带上分享人ID，用来核算社区团长的佣金。当然，这些功能不能做得太野，分享和跳转都得符合微信的规则，这个后面在踩坑部分再细说。
2. 系统总览：模块划分与订单状态机
2.1 六大核心模块
整个系统虽然名字叫“云订单零售系统”，但核心其实就六大块：商品中心、用户中心、库存中心、订单中心、支付中心、履约中心。我把它们拆成模块，但没有一开始就上微服务。项目初期团队就五六个人，门店数量也不多，直接上Spring Cloud那套分布式架构，运维成本会吃掉大半开发时间。所以我采用了“单体架构、模块化代码”的方式：一个Spring Boot应用，按业务域分包，数据库还是单库，这样既能保证开发效率，又为将来拆服务留了边界。
每个模块的职责：
- 商品中心：维护SPU/SKU、规格参数、图文详情、上下架状态，以及“生鲜特有”的日库存批次信息。比如一批菠菜的入库时间、数量、预计到期时间，都挂在库存批次的维度上。
- 用户中心：微信授权登录、手机号绑定、收货地址、优惠券、会员等级。
- 库存中心：管理可售库存、锁定库存、实际库存，以及库存流水。这是整个系统最容易出问题的模块。
- 订单中心：负责下单、订单状态流转、订单查询、订单拆分，以及超时取消和支付对账。
- 支付中心：处理微信支付的预下单、支付回调、退款、提现对账，还要维护支付流水表。
- 履约中心：推送拣货单到门店、管理配送批次、骑手派单、签收确认。
这些模块里，库存中心和订单中心的关系最紧密。我专门在订单表里不直接存库存快照，而是通过订单明细里的sku和quantity去引用库存流水，这样任何一个环节出问题都能追溯。
2.2 生鲜订单状态机的设计
生鲜订单的状态不能照搬普通电商的“待付款、已付款、已发货、已完成”，因为还有门店拣货这个环节。我设计的状态转换如下：
| 状态 | 触发条件 | 下一步状态 |
|---|---|---|
| 待支付 | 用户下单成功 | 已支付 / 已取消 |
| 已支付 | 微信支付回调成功 | 待拣货 |
| 待拣货 | 门店接单 | 拣货中 |
| 拣货中 | 店员完成拣货 | 待配送 |
| 待配送 | 骑手取件 | 配送中 |
| 配送中 | 用户签收 | 已完成 |
| 售后中 | 用户发起售后申请 | 退款完成 / 已完成 |
| 已取消 | 超时未支付 / 用户主动取消 | 终态 |
这里需要注意，生鲜订单不是所有的“已支付”都立刻进入“待拣货”的。有些用户选择“到店自提”，那么支付后状态要变成“待自提”，相当于待拣货后没有配送环节。我在订单表里加了一个fulfillment_type字段，取值是delivery或pickup，状态机在“待配送”之前分叉。
另外，生鲜订单很少做“仅退款不退货”，因为很多商品是食品，退回后再销售有安全隐患。所以售后状态我分了两条线：未发货的订单直接“退款关闭”，已发货的订单走“申请售后-同意退货/仅退款-退款完成”。这个在后面逆向流程部分会细讲。
2.3 云端部署与数据结构要点
部署上我直接用了一台云服务器，配置不高，4核8G，跑Spring Boot加MySQL没问题。高峰期靠带宽和CDN撑静态资源，数据库扛不住的时候先用Redis顶。这套方案的成本每个月几百块，对单店或三五家店的连锁完全够用。如果将来门店数翻到几十家，再把订单库和商品库分开，引入读写分离，也比一开始就上K8s要省力得多。
数据库设计上，有三个我特别坚持的细节：
订单号用雪花ID。生鲜订单并发生成，如果用自增ID，用户会通过ID推测出当日订单量，而且在多门店场景下自增ID会乱。雪花ID能保证全局唯一、趋势递增，对接微信支付、导出Excel都方便。
订单表的核心查询维度是“门店ID + 下单日期 + 状态”。我建了联合索引
(store_id, created_at, status)。有人觉得status放索引后面没有用，实测因为生鲜门店订单通常几千单一天，这个索引已经能把扫描行数降到几十，再配合分页就够了。库存流水表用追加写，不做更新。每次扣库存、回补库存都insert一条流水，字段是
sku_id, order_id, change_type, change_quantity, before_stock, after_stock。查看一个SKU的历史变化，直接查流水表就能还原，排查超卖和数据不一致再也不用求着DBA做数据恢复。
3. 核心链路实现：从加购到支付成功，库存怎么锁才不超卖
3.1 小程序端购物车与下单参数组装
小程序端我们用的原生微信小程序框架，没有上vue或uni-app，因为生鲜业务页面不算特别复杂，原生开发反而能直接用微信生态的能力，比如订阅消息和分享卡片。
购物车模块有个反直觉的点：生鲜商品是按“份”卖的，比如“半斤装菠菜”是一个SKU，“1斤装菠菜”是另一个SKU。这样设计是为了让库存锁定更精确，不然用户在规格里填“0.6斤”，库存没法扣。下单接口接收的参数大概是：
{ "userId": "wx_openid_xxx", "storeId": 1024, "fulfillmentType": "delivery", "deliveryInfo": { "name": "张三", "phone": "13800000000", "address": "XX路XX小区X栋X室", "deliveryTime": "2025-07-01 18:00-20:00" }, "items": [ { "skuId": 12345, "quantity": 2 }, { "skuId": 12346, "quantity": 1 } ], "paymentType": "wechat_miniapp" }后端拿到这个参数后，第一步不是先写订单，而是做三件事：校验SKU是否上架、校验门店是否支持该配送时段、计算价格。价格计算我放在后端做，没有信任前端传过来的金额，防止用户篡改接口把商品价格改成1分钱。前端价格只做展示，后端根据最新的商品表和优惠券重新计算。
校验通过后，就进入库存锁定环节。
3.2 库存预占与超卖防护
超卖是每个订单系统都必须面对的问题。生鲜的库存数字变化很快，店员可能一边卖货一边礼盒打包，如果不做锁库，线上订单会把门店库存扣穿，最后导致线下没货可卖。
我的方案分两层：
第一层，Redis做缓存预判。每个SKU在Redis里有一个可售库存的key，下单时用Lua脚本原子地检查并扣减。Lua脚本大致逻辑：
local available = tonumber(redis.call('get', KEYS[1])) if not available or available < tonumber(ARGV[1]) then return 0 end redis.call('decrby', KEYS[1], ARGV[1]) return 1这个方案能挡住绝大部分并发请求，但Redis里的库存数据终究是从MySQL同步过来的，一旦延迟，就会出现Redis显示有货但MySQL已经没有货的情况。所以第二层，我用MySQL的乐观锁兜底：在真正生成订单明细前，执行一条带条件的更新语句。
int rows = skuStockMapper.deductStock(skuId, quantity); // SQL: UPDATE sku_stock SET available_stock = available_stock - #{quantity} // WHERE sku_id = #{skuId} AND available_stock >= #{quantity}如果rows == 0，说明库存不足，订单就要回滚，同时还要把Redis里已经扣掉的数字回补。这里有一个顺序问题：先扣Redis再扣MySQL，如果MySQL扣失败，必须即时回补Redis。我通过本地事务里监听回滚事件来补偿。
这只是“锁定库存”的完成态。实际上订单还没有支付，所以库存要分成“预占”和“实占”两个概念。我设计了sku_stock表里三个字段：
total_stock：商品实际到货总库存available_stock：可售库存（total_stock - lock_stock - 已售数量）lock_stock：锁定库存（待支付订单占用的量）
下单时扣减available_stock，同时增加lock_stock；用户支付成功后，把lock_stock转成“已售”；订单超时关闭后，回补available_stock并减少lock_stock。这样任何时候查询可用库存，数字都不会被未支付订单“虚占”。
3.3 微信支付回调的幂等处理与订单自动取消
接了微信支付之后，最头疼的不是第一次拉起支付，而是回调通知可能到达多次。微信服务器在回调失败后会重试，如果重复处理回调，订单会被重复加积分、重复通知门店拣货。
我的经验是：回调处理第一件事不是改订单，而是先查支付流水表。支付流水表唯一索引是out_trade_no。如果流水已经存在，直接返回成功给微信，不重复处理。
伪代码如下：
@RestController public class WechatPayCallbackController { @PostMapping("/api/pay/wechat/callback") public String callback(@RequestBody String xmlData) { // 1. 验签，确认是微信发的 WechatPayResult result = wechatPayService.verifyCallback(xmlData); if (!result.isSuccess()) { return "failure"; } // 2. 幂等判断 PayLog payLog = payLogMapper.selectByOutTradeNo(result.getOutTradeNo()); if (payLog != null) { return "success"; // 已处理过 } // 3. 本地事务内创建支付流水并更新订单 try { payLogMapper.insert(PayLog.create(result)); orderService.markPaid(result.getOutTradeNo()); return "success"; } catch (DuplicateKeyException e) { // 并发重复插入，也当成功返回 return "success"; } } }注意，响应给微信的字符串一定是"success"而不是"SUCCESS"或JSON。微信支付的回调需要返回小写success，否则会一直重试。
至于订单自动取消，我用的方案是延时消息。下单成功时，往RocketMQ发一个延迟消息，延迟30分钟，消息内容是订单号。消费者收到消息后先判断订单是否仍然在“待支付”状态，是的话就关闭订单并回补库存。之所以不用定时扫描，是因为定时扫描会有分钟级延迟，高峰期堆积大量过期订单，而延迟消息能精确到秒级。
这里还有一个边界场景：用户微信上明明支付成功了，但我们的回调还没到，本地订单还停留在“待支付”。用户投诉说“我付了钱但订单被取消了”。所以我做了一道“查单兜底”：订单关闭前，主动调用微信支付查询接口，如果返回的订单状态是已支付，则先把本地订单改成已支付，再走后续流程。这个操作在关闭订单的延时消息消费者里执行，保证了不会误关已支付的单。
4. 履约与逆向流程：拣货、配送和退款所踩的坑
4.1 订单推送拣货与配送调度
支付完成之后，订单不能直接丢给门店店员去挨个处理，那样高峰期会更乱。我们设计了一个“波次”概念：系统每隔10分钟把当前门店“待拣货”的订单聚合成分散的任务，生成一张拣货单。拣货单上按商品维度汇总了数量，店员可以一次性把一批货拣齐，再由核货员按订单分装。
拣货单的结构类似：
| 拣货单号 | 门店 | 波次 | 商品SKU | 需求量 |
|---|---|---|---|---|
| P20250701-001 | 1024 | 10:30 | 菠菜半斤装 | 15份 |
| P20250701-001 | 1024 | 10:30 | 五花肉1斤装 | 8份 |
门店店员按汇总单去把货从冷库拿出来，然后扫描拣货单条码，后台就自动把对应的一批订单状态推进到“拣货中”。等店员点“分装完成”，这些订单会变成“待配送”。
配送调度是另外一个模块。我们采用“配送时段 + 容量”的模型：每个门店按天配置配送时段，比如9:00-11:00、16:00-18:00，每个时段的最大订单量是80单。下单时后端会检查该时段剩余容量，如果已满，前端就把那个时段置灰。这样能避免配送员跑不过来导致大量超时投诉。
4.2 配送时段、天气与订单容量
生鲜配送有一个普通快递不会遇到的挑战：恶劣天气。下雨天大家都不爱出门，订单量反而飙升，但配送员的配送效率因为路滑和视线差而下降。如果系统还按原容量接单，骑手跑到晚上也送不完。
我们的临时应急策略是在后台设置“熔断阈值”。当某个配送时段的实时订单量达到该时段容量的90%时，系统自动关闭新订单，并给运营推送报警，由人工决定是加开一个配送时段，还是临时调高单量上限。因为生鲜门店大部分自备配送员，单量高峰时还可以临时调人，所以这个人工介入是有必要的。
天气响应的算法其实很简单，我们接入了免费的天气接口，判断未来两小时是否有暴雨、大雪等恶劣天气，如果是，就把每个配送时段容量下调20%，同时把预计送达时间提示从“最快1小时”改成“可能延迟1-2小时”。这样做能减少用户的预期落差，配送环节的差评率明显下降。
4.3 退换货与财务对账的逆向订单
生鲜售后比电商售后更麻烦，因为“退货”对食品来说很难二次销售。我的设计是：如果商品未发货（订单还在待拣货/拣货中），用户申请退款后，系统直接自动同意，原路退回，同时回补库存。如果商品已经在配送途中，则用户要申请“售后”，需要上传凭证，由门店客服介入处理。客服审核同意后，系统生成退款单。
退款的关键在于：不能直接调用微信退款接口用订单号退款。因为一个订单可能包含多个商品，部分退款是常见操作，如果退款单复用订单号，第二次退款时会因为“商户退款单号重复”而失败。所以我单独设计了一张refund_order表，退款单号是独立生成的，比如前缀“RF”+雪花ID。
生成退款单后，系统调用微信支付退款接口，微信会异步返回退款结果。退款成功后，还要回补对应SKU的库存（如果该商品没有实际消耗），并更新订单状态到“售后完成”。财务每天会对这张表做对账，核对refund_amount与微信支付商户后台的退款金额是否一致，少了就报警。
5. 实战踩坑记录：五件让我重写代码的破事
5.1 微信支付回调不能放在事务里发请求
第一版代码，我在支付回调里同时做了“更新订单状态”和“调用微信查询订单详情”两件事，而且都放在一个事务方法里。结果线上出现数据库连接池被打满，所有接口都卡死。原因很简单：事务开启时，数据库连接就一直被占用；事务方法里同步调微信接口，微信响应慢，连接池很快被耗尽，其他请求拿不到连接就堆积超时。
后来我改成了两个阶段：第一阶段，本地事务内只落支付流水和更新订单状态，然后立即返回success给微信；第二阶段，通过Spring的@Async或者消息队列去调用微信查单、推送履约通知。记住一个原则：凡是外部IO（调用微信、发短信、推送消息）都不要放在本地数据库事务里。
5.2 减库存用“先查后减”导致超卖
开发初期为了赶进度，我在扣库存的Service里写了这样的逻辑：
Stock stock = stockMapper.selectBySkuId(skuId); if (stock.getAvailableStock() < quantity) { throw new InsufficientStockException(); } int rows = stockMapper.updateStock(skuId, stock.getAvailableStock() - quantity);这段代码在单线程下没问题，一旦用户同时下单，两次请求都读到了同一个availableStock，都判断库存充足，都执行更新，结果销售数量超过实际库存。很多时候我们觉得“这是教科书案例，不会发生在自己身上”，但它真的会发生。
我最终的修复方法是上面讲到的条件更新：
UPDATE sku_stock SET available_stock = available_stock - #{quantity} WHERE sku_id = #{skuId} AND available_stock >= #{quantity}并且检查返回的影响行数。如果为0，就说明并发扣减没有抢到，需要回滚。这个方案不需要引入分布式锁，性能也够用。
5.3 同一门店并发配送高峰如何限流降级
有次门店做“满99减20”活动，流量瞬间上来，结果小程序端接口还好，但下单接口的数据库CPU直接飙到100%，用户下单全部超时。当时没有限流，没有降级，整个门店线下收银都受影响了。
之后我在下单接口前加了一层Redis分布式限流，按门店维度每秒最多处理10个下单请求，超出部分直接返回“当前下单人数过多，请稍后再试”。同时下单请求先进MQ队列，后端Worker按固定速率消费，把并发压力削平。真正的高峰虽然是短暂的，但系统不能因为瞬时流量就整体崩掉。现在回头看，这种保护措施已经成了标配。
5.4 小程序分享订单链接的scheme兼容问题
小程序里经常需要发分享卡片到微信群，用户点击卡片进入小程序。开发时我注意过“weixin://dl/business”这类scheme在iOS和Android上的兼容性问题，有的机型直接无法跳转。
因为微信官方对小程序的打开路径有明确规范，业务跳转不应该自己拼scheme，而是通过wx.miniProgram.navigateTo或者生成正常的page路径。尤其在分享卡片上，应该用微信提供的open-type="share"能力，后台通过share_ticket或scene参数来追踪渠道。如果强行在Web环境里塞“weixin://dl/business”这类链接，不但可能被限制，还容易在不同版本的微信客户端上出现“打不开”的情况。
我最后的做法是：所有分享卡片统一走小程序原生的onShareAppMessage，附带自定义参数scene=spread_xxx，用户点卡片进入后，在小程序启动参数里读取来源ID。这样既符合平台规则，又拿到了推广追踪数据。
5.5 退款单号用外部单号还是内部单号
曾经我在退款表里直接用订单号当“商户退款单号”，第一次退款成功，第二次部分退款时就报“商户退款单号重复”。微信支付要求每次退款操作的商户退款单号必须唯一，而一个订单可以多次退款。
之后我改成每次创建退款单时，生成一个带时间戳加随机位的退款单号，比如RF2025063012000012345。这个单号既用于微信支付退款接口的out_refund_no参数，也作为我们系统内部退款表的业务主键。客服在后台操作退款时，绝不会因为重复点击而生成两条相同退款单。
6. 复盘与能复用的经验
6.1 技术选型的“少即是多”
做完这个项目，我最大的体会是：生鲜云订单系统没那么复杂，但也不能照搬大厂的架构。我看到过很多同行一上来就规划微服务、分库分表、消息中间件集群、容器编排，结果门店只有几家，维护成本比业务成本还高。我们当时用一台云服务器、一个Spring Boot应用、一个MySQL库、一个Redis，加上RocketMQ做任务削峰，就解决了所有业务问题。技术选型要跟着业务规模走，先活下来再谈弹性。
具体到轮子的选择上，订单状态机一定要设计好，但不要引入复杂的流转引擎。生鲜订单的状态就那么十几个，用一张状态机表和简单的if-else判断已经足够。真正值得花时间的是库存对账和支付对账，这两块一旦出问题，损失的是真金白银。
6.2 给后来者的开发顺序建议
如果让我重新做一遍，我会把开发顺序调整为：先做库存中心，再做支付中心，然后才是订单中心，最后做履约和售后。为什么？因为库存是生鲜业务的地基，库存不对，订单越多亏损越多；支付是对账的命脉，支付流水不完整，财务和用户都找不到依据；订单中心只是连接库存和支付的壳，把前两者做好，订单反而简单。
履约和售后可以放在第二期再做。一开始只做“在线下单、到店自提”，等验证了商业模式，再上配送和售后，会少走很多弯路。实际开发中，我还建议每天跑一次对账脚本，把线上订单、支付流水、库存流水三项数字拉平，放在一张报表里，哪怕出问题也能第一时间发现。
这个项目上线之后，我做得最多的一件事不是写新功能，而是盯着对账报表。数据对了，系统就稳了。生鲜零售的生意，说到底就是对“鲜”的把控——库存不烂在仓库里，订单不烂在系统里，用户就不会跑到别家去。
