佚格麻瓜直接说结论：一个能真正跑起来的“Python + 微信小程序”线上水果店商城配送系统，核心难点根本不在“写代码”，而在于把生鲜电商特有的业务规则——称重商品、配送时效、损耗率、售后赔付——塞进一套标准的电商交易流程里。我前前后后做了两版才把整个链路跑顺，这篇文章把完整的项目拆解、后端接口设计、小程序端交互、微信生态对接，还有上线后真机调试那一堆破事全部写清楚。不管你是打算自己接单做外包，还是给线下水果店做私域商城，这篇都值得存下来当参考底稿。
1. 为什么不是套个电商模板，而是自己搭一套“Python + 小程序”水果商城
先说一个很现实的问题：市面上的电商小程序模板一抓一大把，直接套一个不香吗？我当初也这么想过，但真拿生鲜水果的业务往里套的时候，发现至少有三个坎过不去。
1.1 水果生鲜和标品电商的差异
普通电商卖的是标准品，SKU稳定，库存精确到“件”，物流走快递，用户下单后等两三天收货，基本没有时效焦虑。但水果店完全不是这么回事。
第一，水果是称重商品。用户要买的是“一斤苹果”而不是“一箱苹果”，价格随行情波动，今天和明天的进价可能不一样。这意味着商品表里必须有“按斤计价”和“按份计价”两套逻辑，不能简单写死一个price。
第二，库存不是简单数字。一箱香蕉进货50斤，卖出去的可能不是整斤整两，而且水果有损耗，今天磕坏了两斤，实际可卖库存就变了。如果系统里只存一个整数库存，早晚会出问题。
第三，配送时效是硬指标。水果不比衣服，用户今天下单基本就想今天送到，甚至希望指定“下午三点前送到家”。这就要求订单系统必须支持配送时段、配送区域、配送费用等多维度的规则配置。
1.2 技术选型：后端为什么是Python，而不是Java/Node
我见过不少人上来就纠结语言，其实没必要。就这个项目体量来说，Python的Django或Flask完全够用，而且开发效率确实高。
我最终选了Django + Django REST Framework的组合。原因很实在：
- Django自带Admin后台，运营人员可以直接在后台上架商品、调整价格、查看订单，省掉一整套管理端前端的开发量。
- ORM的模型管理对电商这种强数据结构的业务非常友好，订单、商品、用户、配送这几个核心模型之间的关系可以很清晰地用代码表达。
- DRF的序列化器和视图集让接口开发速度提升明显，写一套CRUD基本就是几十分钟的事。
- Python生态里处理微信支付、微信登录这些对接，都有现成的SDK和大量踩坑案例，遇到问题搜得到答案。
如果你只是想快速验证业务，Flask也行，但Django这种“全家桶”风格的项目结构，对于后续维护和加功能会省心很多。
1.3 业务闭环：系统到底要管哪些事
把需求完全梳理清楚之后，这个系统的业务闭环实际是这样的：
用户在小程序里浏览商品 → 加入购物车 → 提交订单（选择配送地址和时间段）→ 微信支付 → 商家在后台接单 → 配送员拣货配送 → 用户确认收货 → 售后/评价。
这条链路上，系统需要具备的核心模块是：
- 用户端小程序：首页、分类、商品列表、商品详情、购物车、下单结算、订单列表、订单详情、售后申请。
- 商家管理后台：商品管理（上下架、价格库存）、订单管理（接单、改价、发货）、配送管理（配送员派单、送达确认）、营销管理（优惠券、满减）、数据统计。
- 后端API服务：用户鉴权、商品接口、购物车接口、订单接口、支付回调、配送状态更新、售后接口。
- 消息触达服务：订单状态变更通知、配送提醒（微信订阅消息）、营销推送。
这套体系不算复杂，但环环相扣。下面从数据库建模开始，把每个关键环节的落地细节都讲一遍。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 项目启动前必须想明白的三个核心问题
很多半路夭折的项目，不是死在编码上，而是死在前期设计上。尤其是水果店商城这种业务，有三个问题如果没想清楚就动手，后面返工的成本极高。
2.1 商品模型：别把“斤”和“份”做死
第一个必须想明白的，是商品规格问题。水果店里的商品通常有三种售卖方式：
- 称重计价的散装商品，比如苹果、香蕉，按500g或1000g计价。
- 固定份量的包装商品，比如一盒草莓、一份果切拼盘。
- 礼盒/整箱商品，比如一箱车厘子、一箱猕猴桃，价格固定且不可拆。
在设计商品表时，我引入了规格(specification)的概念，把每种售卖方式抽象为一个SKU。一个商品下可以有多个SKU，每个SKU包含：
- 规格名称（如“500g±50g”“1盒约300g”“整箱5斤装”）
- 售卖方式（weight：称重计价，quantity：按件计价）
- 单价（按斤卖时是每500g的价格，按件卖时是单件价格）
- 库存数量（如果按重量卖，库存单位是克；按件卖，库存单位是件）
- SKU图片、排序权重
这样设计的好处是，用户在前端切换规格时，价格和库存自动联动，后台上新也好操作，只要给商品添加一个新的SKU就行。
2.2 库存和损耗：生鲜的扣减逻辑和普通电商完全不同
普通电商的库存扣减是“下单减库存”或“支付减库存”，但对水果店来说，库存还有一个“损耗”的概念。
我第一版就吃了亏，直接在商品表里存了一个库存数字，结果运营每天都要手动改库存，因为实际售卖过程中，损耗、称重误差、门店调拨都会导致库存对不上。
后来我做了一个小调整：在SKU上增加“预警库存”字段，并单独建了一张库存流水表（stock_log）。每次发生库存变动（用户下单、人工调整、盘点修正、报损）都写一条流水，后台可以看到库存变化的全链路。这样运营只需要做每日盘点，把实际库存修正进去，系统自动记录差额，损耗率也能统计出来。
这个设计对水果店这种损耗高的品类尤其重要。没有流水账，你根本不知道每天到底损耗了多少，月底盘点对不上账还想查原因？无从查起。
2.3 配送范围与履约节点：不是简单填个地址
水果店的配送通常是同城或同区配送，有的店只有周边3公里能送。这就引出了两个问题：
配送范围怎么界定？我见过有人傻乎乎地在前端让用户手动选“能否配送”，这体验太差了。正确做法是后端根据用户填写的收货地址经纬度，计算与门店的距离或判断是否在预设的配送多边形范围内，下单接口直接返回“当前地址不在配送范围”或“当前时段已约满”。
配送时段怎么管理？水果店配送运力有限，高峰期（比如下班时间）很容易爆单。我的做法是让后台配置每天的配送时段，比如10:00-12:00、14:00-16:00、16:00-18:00、18:00-20:00，每个时段设置最大接单量，用户在结算页选择配送时段时，后端实时校验该时段是否还有名额。
这两个点如果前期没设计好，后面接配送模块的时候就会处处受制。
3. 后端接口设计与数据库建模实战
整个项目的后端我用的是Django + DRF，数据库用的MySQL。下面把核心的表结构和接口设计过一遍，这些都是可以照抄的设计。
3.1 数据表拆分：商品、SKU、购物车、订单、配送单
完整的表结构不止下面这些，但核心的这几张表必须设计清楚：
- category：商品分类表，字段包括name、sort_order、is_show。
- goods：商品表，字段包括name、main_image、images（JSON存的轮播图列表）、description、status（on/off）、sales（销量）、category。
- goods_sku：商品规格表，字段包括goods、spec_name、sell_type、price（Decimal）、stock、warning_stock、image。
- user：用户表，字段包括openid（微信openid）、nickname、avatar、phone、balance、status。这里直接用Django自带的User扩展也行，但建议单独建一张profile表存业务字段。
- user_address：收货地址表，字段包括user、receiver_name、receiver_phone、province、city、district、detail、lng、lat、is_default。
- cart：购物车表，字段包括user、sku、quantity、selected（是否勾选）、create_time。
- order：订单主表，字段包括order_no（订单号）、user、total_amount、freight_amount、discount_amount、pay_amount、pay_status、order_status、remark、address_snapshot（下单时地址快照）、delivery_time_slot、create_time。
- order_item：订单明细表，字段包括order、sku、goods_name、spec_name、price、quantity、subtotal。
- delivery：配送单表，字段包括order、delivery_type（门店自提/同城配送）、delivery_status、delivery_time、deliveryman、complete_time。
- payment：支付流水表，字段包括order、transaction_id（微信支付单号）、amount、status、pay_time。
订单表里存address_snapshot这个字段是很多新手容易忽略的。用户下单后修改了收货地址，不应该影响已经生成的订单，所以下单那一刻就要把地址信息冗余到订单表里。
3.2 登录态与用户体系：小程序 code2Session 流程
小程序的登录逻辑是：wx.login 获取 code，发给后端，后端用 code 换 openid 和 session_key，然后后端自己签发一个 token 返回给小程序。后续所有需要鉴权的接口，小程序在请求头里带上 token 即可。
Django 这边我用的是 rest_framework_simplejwt 来签发 JWT token。核心接口逻辑如下：
python复制# apps/user/views.py
import requests
from rest_framework.views import APIView
from rest_framework.response import Response
from rest_framework_simplejwt.tokens import RefreshToken
from .models import User
APPID = "your_appid"
SECRET = "your_app_secret"
class WxLoginView(APIView):
def post(self, request):
code = request.data.get("code")
url = "https://api.weixin.qq.com/sns/jscode2session"
params = {
"appid": APPID,
"secret": SECRET,
"js_code": code,
"grant_type": "authorization_code",
}
resp = requests.get(url, params=params).json()
if "openid" not in resp:
return Response({"code": 401, "msg": "登录失败，请重试"}, status=401)
openid = resp["openid"]
user, _ = User.objects.get_or_create(openid=openid)
refresh = RefreshToken.for_user(user)
return Response({
"code": 0,
"data": {
"token": str(refresh.access_token),
"user_info": {"id": user.id, "nickname": user.nickname or "微信用户"}
}
})
这里必须要提醒：不要把 app_secret 暴露在小程序端，所有微信接口的调用必须走后端。有些人图省事在小程序里直接调微信接口，secret 一旦泄露，别人就能用你的 appid 去调用微信能力做坏事。
另外，现在微信对 getUserProfile 和 getUserInfo 的授权策略改过很多次，头像和昵称现在有独立的头像昵称填写能力。我的做法是：用户默认显示微信头像昵称，但如果需要，允许用户在个人中心手动修改昵称和头像，把修改后的值传给后端存储。不要强行要求用户授权，否则审核会有风险。
3.3 商品与购物车接口的关键字段
商品列表接口，前端需要的数据结构大概是这样的：
json复制{
"id": 1,
"name": "海南金钻凤梨",
"main_image": "https://cdn.example.com/pineapple.jpg",
"price": "9.90",
"unit": "500g",
"sales": 120,
"skus": [
{"id": 11, "spec_name": "1个装（约1kg）", "price": "19.90", "stock": 30},
{"id": 12, "spec_name": "2个装（约2kg）", "price": "35.90", "stock": 10}
]
}
列表页不需要返回全部SKU，只返回默认SKU的价格即可，详情页再拉全量SKU数据。这样列表接口的响应体更小，加载速度更快。
购物车的设计也简单，cart表里存sku_id和quantity即可。需要注意的一点：加入购物车时要对库存做一次校验，如果库存不足，直接提示“库存不足”，而不是等结算时才报错。
3.4 下单接口：事务、库存校验、幂等
下单是整个系统的核心接口，最容易出问题。我的实现分为四步，包在 Django 的事务（transaction.atomic）里：
第一步，创建订单主表记录，状态为“待支付”。
第二步，遍历用户勾选的购物车条目，逐条校验SKU库存。如果任一SKU库存不足，整体回滚，返回“XX商品库存不足”。
第三步，扣减SKU库存，写入库存流水。这里要注意：必须先 SELECT ... FOR UPDATE 锁定行，再 UPDATE 扣减，防止并发超卖。
第四步，清空购物车中已下单的条目，把订单明细写入order_item表。
这里有一个幂等性的问题：用户可能因为网络原因重复点击“提交订单”，导致生成两笔一模一样的订单。我的处理方式是在前端生成一个 client_token（UUID），提交订单时带上，后端用这个字段做唯一约束，同一个client_token只能创建一个订单。
python复制# apps/order/views.py
from django.db import transaction
from django.db.models import F
from rest_framework.views import APIView
from rest_framework.response import Response
from .models import Order, OrderItem, Cart
from apps.goods.models import GoodsSku
class CreateOrderView(APIView):
def post(self, request):
user = request.user
client_token = request.data.get("client_token")
if Order.objects.filter(client_token=client_token, user=user).exists():
return Response({"code": 400, "msg": "请勿重复提交"})
with transaction.atomic():
# 这里做库存校验和扣减
skus = GoodsSku.objects.select_for_update().filter(id__in=sku_ids)
for sku in skus:
if sku.stock < quantities[sku.id]:
return Response({"code": 400, "msg": f"{sku.goods.name} 库存不足"})
# 扣库存 + 写流水
# 创建订单 + 订单明细
pass
return Response({"code": 0, "data": {"order_no": order.order_no}})
下单接口是并发密集型操作，一定要写好压测。我当时用简单脚本并发100个请求模拟同一SKU下单，发现如果没加 select_for_update，库存会出现超卖，加了之后就没再出现过。
4. 微信小程序端核心页面与交互拆解
小程序端我用的是原生框架，没有引入uni-app或Taro，原因是项目本身不算大，原生框架的加载速度和稳定性更可控。如果你需要同时支持支付宝小程序或App端，那可以换uni-app，不用纠结。
4.1 首页与分类：数据加载和缓存策略
首页是水果店的门面，信息密度不能太低，但也不能一把梭全塞进去。我的首页从上到下分这几个模块：
- 搜索栏和门店公告
- 轮播图（运营位，跳转活动页或商品详情页）
- 金刚区图标（分类快捷入口）
- 爆款推荐（按销量排序的商品列表）
- 新人专享/限时秒杀（营销模块，可后端配置）
为了首屏加载速度，首页用了“骨架屏 + 异步加载”的策略：先渲染一个静态骨架，数据返回后再填充。分类部分采用左侧一级分类 + 右侧二级分类+商品列表的经典布局，数据一次性返回，前端本地做过滤，避免频繁请求。
4.2 商品详情和SKU选择组件的实现
商品详情页的主要交互是SKU选择和加购/立即购买。SKU选择器我封装了一个组件，逻辑是这样的：
- 根据后端返回的SKU列表，渲染出规格按钮。
- 默认选中第一个有库存的SKU。
- 用户切换规格时，联动更新价格、库存、图片。
- 如果某个SKU库存为0，按钮置灰不可选。
这个组件细节多，但逻辑不复杂，关键是一个数据结构设计：
javascript复制skuValues: [
{ id: 11, spec_name: "1个装", price: 19.9, stock: 30, image: "..." },
{ id: 12, spec_name: "2个装", price: 35.9, stock: 10, image: "..." }
]
前端把这个数组渲染成按钮，用当前选中的sku id去查找对应信息。不需要做复杂的SKU组合算法，因为水果店场景下，每个商品本身SKU数量就不多，没必要上“规格组合矩阵”。
4.3 购物车与结算页：从勾选到生成订单
购物车页需要注意的交互点：
- 每个商品条目左侧有勾选按钮，顶部有“全选”。
- 底部实时计算已选商品总价。
- 左滑商品可删除，右上角可进入“管理”模式批量删除。
- 点击“结算”进入确认订单页。
结算页的数据包括：收货地址卡片、商品清单、配送时段选择、配送费、优惠券、订单备注、支付方式（默认微信支付）、合计金额。
这里我踩了一个坑：优惠券的满减逻辑。如果优惠券门槛是“满50减5”，那么是“商品总价满50”还是“商品总价+配送费满50”？边界规则必须明确。我的做法是只按商品总价（不含配送费）计算是否满足门槛，配送费不参与满减，但优惠券可以抵扣配送费。这个规则在页面上要写清楚，不然用户会有歧义，客诉率很高。
4.4 订单状态展示与配送进度
订单状态我用一个枚举值表示：
- 10：待支付
- 20：待接单（支付完成，商家未确认）
- 30：待配送（商家已接单，正在拣货）
- 40：配送中（配送员已取货）
- 50：已完成（用户确认收货或系统自动确认）
- 60：已取消
- 70：退款中/已退款
订单列表页按状态分Tab展示，每个订单卡片有对应的操作按钮，比如待支付订单可以“取消订单”“去支付”，待配送订单可以“催单”，已完成订单可以“再来一单”“申请售后”。
配送进度我用一个时间轴组件展示，状态节点包括：订单提交、商家接单、配送员取货、送达。每次状态变更时，后端通过微信订阅消息给用户推送一条通知，点开即可看到最新状态。
5. 支付、订阅消息与售后：微信生态的四个能力对接
小程序电商离不开微信支付和订阅消息，这两个能力对接好了，用户体验才算完整。
5.1 JSAPI支付的完整流程
微信小程序内支付走的是JSAPI支付。流程分两段：
后端先调用微信支付统一下单接口，拿到 prepay_id，然后返回给小程序端一组支付参数（timeStamp、nonceStr、package、signType、paySign）。
小程序端拿到这些参数后，调用 wx.requestPayment 拉起收银台，用户输入密码完成支付。
支付结果以微信服务器回调为准，不能以小程序端回调为准。所以要写一个支付回调接口，微信会把支付结果POST到这个接口，后端更新订单状态、标记支付流水、开始后续的拣货配送流程。
回调接口需要注意：必须验证签名，并校验订单金额。我之前遇到过一个问题，回调里如果只校验订单号不校验金额，有被篡改的风险。正确的做法是回调里不仅校验签名，还要把回调里的amount和数据库里的订单金额做比对，完全一致才更新状态。
5.2 订阅消息：配送通知如何触达用户
订阅消息的机制是：用户主动订阅后，小程序可以给用户发一次“一次性订阅消息”。也就是说，用户点了“允许订阅”，你才可能给他发一条；没点，你就发不了。
在订单流程里，我的做法是在用户提交订单成功但还没支付的时候，弹一个订阅消息授权框，让用户订阅“订单配送通知”。用户点击“允许”后，下单成功、配送员取货、送达这三个节点各可以发一条订阅消息。
注意wx.requestSubscribeMessage必须由用户点击行为触发，不能在onLoad里静默调。我见过有人把这个API放在页面加载时调用，结果一直没弹窗，排查了半天才发现是触发条件不满足。
5.3 退款与售后闭环
水果生鲜的售后率天然比标品高，所以售后流程一定要顺畅。我的售后模块支持两种类型：
- 仅退款：订单未发货或用户不想要了，申请退款。
- 退款退货：商品有质量问题（坏果、腐烂），上传凭证（图片）申请退款退货。
安卓iOS这类问题先不谈，关键是退款审核的流程：用户在小程序端提交售后单 → 商家在后台查看凭证（图片）→ 商家同意退款，调用微信退款接口原路退回 → 用户收到退款。
微信退款接口（refund）需要商户证书，这里也有一个常见的坑：本地开发环境和服务器环境必须都配置好API证书路径，证书文件不要放在项目代码目录下，而是放在服务器特定目录，通过环境变量引用，否则代码泄露会连带证书泄露。
5.4 用户隐私保护：头像昵称获取的新规
2022年之后，微信小程序获取用户头像昵称的规则改得很严格，wx.getUserProfile 已经不能直接弹出授权框了，需要用户主动点击头像昵称填写能力。具体做法是：在小程序里放一个“头像昵称填写”的button组件，用户点击后，微信会调起官方填写的弹窗，用户确认后返回新的头像临时地址和昵称。
后端需要保存头像时，先用 wx.media.checkAsync 接口校验图片内容是否合规（避免违规图片），然后把临时地址转存到自己的对象存储（OSS/COS）。不要直接存临时地址，临时地址有一定有效期。
这个点很多人会忽略，审核的时候被拒一次就要花好几天重新提审，提前做好能省很多事。
6. 从本地联调到上线，我踩过的坑和排查链路
这个项目的坑不少，下面挑几个最典型的，每一个都是我实际遇到并解决了的问题，完整还原排查过程。
6.1 真机调试 connect timed out 的排查过程
小程序开发工具里一切正常，一真机预览就提示 connect timed out 或者 net::ERR_CONNECTION_RESET。这个问题第一次遇到时真的让人抓狂。
排查链路是这样的：
第一步，先确认是不是手机和电脑不在同一网络。小程序开发工具默认的“不校验合法域名”只对开发工具有效，真机上请求的域名必须是HTTPS且已在小程序后台配置，否则会被拦。
第二步，如果你用本地IP调试，手机和电脑必须在同一个局域网，且电脑防火墙要放行对应端口。我当时就是被Windows防火墙拦了，开发工具里没问题，真机一请求就超时。解决办法：在防火墙高级设置里添加入站规则，允许Python进程访问网络，或者放开对应端口。
第三步，如果局域网调试通了但线上环境仍然超时，检查服务器安全组是否放行了443端口、Nginx是否配置了SSL证书。
这里分享一个经验：真机调试的问题，90%是网络可达性问题，不是代码问题。排查时先用手机浏览器访问一下后端接口地址，能通再查小程序端配置，别一上来就怀疑代码。
6.2 “不在以下 request 合法域名列表中”的坑
开发工具里勾选“不校验合法域名”可以正常访问，但真机一预览就报“不在以下 request 合法域名列表中”。这个问题的本质是：小程序生产环境只允许请求已备案且已配置为合法域名的HTTPS接口。
解决办法是去微信公众平台 → 开发管理 → 开发设置 → 服务器域名，把接口域名添加进“request合法域名”。需要注意：
- 域名必须是HTTPS，且证书必须是受信任的CA签发的，自签名证书不被接受。
- 一个域名对应一个request合法域名，可以配置多个，但数量有限。
- 下载、上传文件需要另外配置downloadFile合法域名和uploadFile合法域名。
- 域名需要是ICP备案的，并且备案主体和小程序主体一致或有关联关系。
这个坑看似简单，但处理起来很恼人，因为你配完可能要等几分钟才生效，而开发的时候未必能立刻意识到是域名配置问题。
6.3 包体积超限与分包实践
小程序主包体积限制是2MB，如果图片不小心传了一大堆进去，或者引入了比较大的库，很容易超限。我的项目第一次打包就超了，因为商品mock数据里用了大量本地图片。
解决办法是：
- 所有图片切换到CDN或对象存储路径，本地不放图片资源。
- 业务代码分包加载：把订单流程、售后流程、商品详情这类非首屏必需的页面放进 subpackage，主包只保留首页、分类、购物车、我的四个Tab页。
- 代码层面的压缩：去掉未使用的组件和工具函数，检查是否有重复引入的库。
分包之后，主包体积从2.3MB降到了1.2MB，首屏加载速度明显提升。这个工作最好在项目一开始就做，中途改分包要动很多页面路径，成本不低。
6.4 库存超卖的复现与修复
这个坑让我印象最深。某次拼团活动，同时有大量用户下单，结果系统出现了库存变成负数的情况，而且订单数量超过了实际库存。排查后定位到原因：库存扣减的逻辑没有加锁，多个请求同时读到相同库存值，然后各自扣减，最后写回的库存值互相覆盖。
复现思路：写一个并发脚本，使用 requests + threading 同时发起100个请求，每个请求购买同一SKU，库存设置成10。跑完之后发现订单创建了20多笔，库存变成了负数。
修复方案就是我前面提到的：数据库层面加锁，用 select_for_update 锁住SKU行再扣减，同时加上“库存充足才允许更新”的条件更新语句。
python复制updated = GoodsSku.objects.filter(
id=sku_id, stock__gte=quantity
).update(stock=F("stock") - quantity)
if updated == 0:
raise ValueError("库存不足")
这种条件更新的方式比select_for_update更简洁，性能也更好，关键是query层面就保证了原子性，不会出现“读出来够、写回去不够”的并发问题。
6.5 时间处理：配送时段和时区
项目上线后，有用户反馈订单显示的配送时段比实际慢了一个小时。排查了半天，发现是数据库连接配置里的time_zone没有设置。MySQL默认使用服务器时区，而Django的TIME_ZONE设置是UTC，两者不一致导致时间在存储和读取时发生偏移。
解决方案：数据库连接参数里显式配置 time_zone='+08:00'，Django的USE_TZ设置为False（如果只服务国内用户），或者统一用UTC+8。这个坑很隐蔽，因为开发环境可能碰巧时区一致，一上服务器就暴露。
我再三强调：凡是涉及下单时间、配送时间、秒杀活动时间的地方，统一用“后端生成的时间字符串”返回给前端，前端不做任何时区转换。时间计算全部由后端完成，前端只做展示，可以避免大量时区相关的低级错误。
7. 配送模块的履约逻辑：把订单变成实际送达
小程序端的订单状态流转只是表面，配送模块内部的状态机和派单逻辑，才是整个履约链路里最容易乱的地方。
7.1 配送单与订单的状态机设计
配送单的状态我独立于订单状态来管理，单独存在delivery表里。这样设计的考虑是：一个订单可能因为某些原因被拆成两单配送，也有多个订单可能合并成一单配送（比如同一用户下了两单，或者同一个配送员顺路送多个订单）。把配送单和订单解耦，灵活性会高很多。
配送单的状态：
- pending：待分配配送员
- assigned：已分配给配送员
- picked_up：已取货
- delivering：配送中
- completed：已送达
- failed：配送失败（用户拒收、地址错误、超时未送达）
配送员端我直接复用了用户小程序的框架，通过角色区分页面。配送员登录后看到的是待接单列表、我的配送单、结算统计。权限控制用Django的group实现，配送员有独立的token和独立接口。
7.2 智能派单：谁离得近谁送
派单逻辑我用了一个很朴素但实用的策略：计算所有空闲配送员当前位置到门店的距离，选最近的派单。如果所有配送员都忙，订单进入待分配队列，等有配送员空闲时再自动分配。
距离计算用的是高德地图API，配送员端定时上报经纬度到后端（间隔30秒，用小程序wx.getLocation），后端存最新位置。计算距离时调用高德的骑行/步行路线规划接口，得到真实骑行距离，而不是简单的直线距离。
城市道路和直线距离差别很大，直线距离2公里可能骑电动车要绕3公里。我当时第一版用的直线距离，结果配送员配送超时率很高，后来换了路线规划接口，准确率高不少。
7.3 配送费的计算规则
配送费是一个很敏感的业务参数，定高了用户不买账，定低了商家亏钱。我的规则设计是：
- 基础配送费：4元。
- 满29元免配送费（后续可根据客单价调整）。
- 超出配送范围按距离加收：超出基础配送范围（3公里）后，每增加1公里加收1元配送费，封顶10元。
- 预约配送时段（比如夜间）加收2元。
这个规则配置成后台可调，运营可以随时改，不需要发版。前端结算页实时调用后端计算配送费接口，商品金额变动、地址变更、配送时段变更都会重新计算。
7.4 配送完成后的确认机制
送达确认有两种方式：用户主动确认收货，或者配送员点击“已送达”。我做了双重机制：配送员点击“已送达”后，系统会给用户发一条订阅消息提醒收货；如果用户一直没操作，订单在配送员确认送达后的24小时自动变成“已完成”。
这里牵扯到售后时效：用户确认收货后可以发起售后，但如果系统自动确认收货了，用户可能已经忘了这件事，后面再发起售后容易产生纠纷。我的做法是：无论订单是用户确认还是系统自动确认，售后入口在订单完成后的7天内始终开放，水果坏果这种问题基本都是当天能发现的，7天足够。
8. 运营后台：运营人员每天要用的那些功能
后端接口和用户小程序只是系统的一部分，真正每天被商家使用的运营后台，设计得好不好直接决定这个系统能不能落地。我用Django Admin + 自定义页面做了这套后台，功能列表如下。
8.1 商品管理的日常操作
运营人员每天要做的商品操作：
- 上架新商品：填写商品名称、分类、主图、详情图、描述，添加SKU和价格。
- 调整价格：水果价格波动大，经常要改，后台直接改SKU价格即可，前端小程序实时生效。
- 调整库存：每日盘点后，把实际库存校准到系统里，库存流水会自动记录差额。
- 上下架：缺货或水果品质不好时，一键下架。
这些操作Django Admin能覆盖大部分，但为了运营人员使用方便，我新增了一个“商品复制”功能，一键复制已有商品信息再修改，特别是同品类不同产地的商品，很实用。
8.2 订单处理的核心逻辑
订单处理是运营后台的日常大头。核心操作有：
- 接单：用户支付后，订单进入“待接单”状态，运营在后台确认订单信息无误后点击接单，订单变为“待配送”。
- 改价：如果用户购买量大有优惠，运营可以直接修改订单金额（改价后用户在小程序端收到差额退款，或者生成新的支付链接）。
- 取消订单：用户申请取消或运营发现异常，直接取消并触发退款。
- 发货：点击发货后，订单进入配送流程，自动分配配送员。
这里有个很实际的细节：订单列表默认只展示“待处理”状态的订单，处理完会自动消失。运营人员不需要在一堆已完成订单里翻找今天的待处理单，大幅提升效率。
8.3 数据统计：今天卖了多少、哪些水果损耗最大
运营后台我加了一个简单的数据看板，展示：
- 今日订单数、今日销售额、今日客单价。
- 今日热销商品Top10。
- 库存预警列表：库存低于预警值的SKU，醒目提示运营补货。
- 近7天销售趋势折线图。
- 损耗率TOP5：根据库存流水里的报损记录统计。
这些数据都是实时查询数据库计算的，数据量不大的情况下直接在页面上展示即可。早期不用上复杂的BI系统，一个后台看板足够用了。
9. 项目做完后的几点总结和扩展建议
项目上线稳定运行之后，我回头整理了一下，有几点体会分享给大家。
整套系统的核心代码量其实不算大，但真正花时间的是业务规则的梳理和调试，尤其是生鲜商品特有的称重、损耗、配送时效这些规则。纯技术框架的复杂度，大概只占整个项目的三成，剩下的七成都是“业务逻辑怎么映射到代码里”的决策。
如果你也想做类似的项目，我的建议是：先从最小可行版本开始，商品模块 + 购物车 + 下单 + 支付 + 配送，这五个环节跑通，就已经是一个可用的系统了。营销、优惠券、售后、分销这些都可以后续迭代加上去，一开始就做全功能只会把自己拖死。
最后一个非常实用的建议：开发环境一定要和生产环境完全隔离，包括微信小程序AppID、微信支付商户号、数据库、云存储。我见过有人把测试用的appid配到生产环境，导致真实用户支付的订单回调到了测试环境，资金对不上，处理起来极其麻烦。环境隔离这件事，越早做越好。