鉴权闭环了。这篇写系统的心脏订单。所有货运业务的复杂度最后都落在订单状态怎么流转这一件事上。状态机先画图再写代码整个订单生命周期只有 6 个状态UNPAID(待支付) ──支付──→ PENDING(待接单) ──司机抢单──→ ACCEPTED(已接单) │ │ │ └──用户取消──→ CANCELLED ←──用户取消──┘ 开始运输 ↓ IN_PROGRESS(运输中) │完成 ↓ COMPLETED(已完成)合法流转表写代码前先列出来比任何文档都管用当前状态允许的动作目标状态UNPAID支付 / 取消PENDING / CANCELLEDPENDING抢单 / 取消ACCEPTED / CANCELLEDACCEPTED开始运输IN_PROGRESSIN_PROGRESS完成COMPLETEDCOMPLETED评价不变凡是表里没有的迁移一律拒绝。比如已接单后用户取消——理论上是允许的司机白跑一趟要补偿但第一版砍掉规则越少客诉越少。下单后端重算价格再强调一次publicLongcreate(CreateOrderReqreq){// 1. 后端重算价格不信任前端金额QuoteRespqpricingService.quote(req.toQuoteReq());// 2. 建订单状态 UNPAIDOrderInfoorderOrderInfo.builder().userId(AuthContext.uid()).status(UNPAID).totalFee(q.getTotalFee())/* ... */.build();orderMapper.insert(order);saveLog(order.getId(),CREATE,用户创建订单);returnorder.getId();}支付本地先用 mock流水先行本地没有微信商户号先做 mock 支付——但钱包流水是真的publicvoidmockPay(LongorderId){introwsupdateStatus(orderId,UNPAID,PENDING);if(rows0)thrownewBizException(订单状态已变化请刷新);walletFlowMapper.insert(PAY记录(order));// 记一笔支付流水saveLog(orderId,PAY,用户完成支付);}注意updateStatus又是那条带条件的 UPDATE乐观锁——支付回调可能重放幂等靠它兜底。将来接真微信支付只是把支付成功的触发点从 mock 接口换成支付回调通知状态机和流水逻辑原样复用。取消与退款只允许 UNPAID / PENDING 状态取消司机已接单后不能单方面取消保护运力。mock 阶段退款也是记一笔逆向流水接入真实支付后换成微信退款 API状态机不变。本篇成果下单 → 支付 → 待接单订单流转前半段闭环每一步都有订单日志和钱包流水。下一篇写司机抢单——10 个司机同时抢一单怎么办那篇有整个项目最精彩的一行代码。