校园外卖小程序 vs 同城外卖小程序：地址模型、调度与对账差异

两类小程序的骨架相同：用户下单、商家接单、骑手配送、平台结算。决定选型的是四个数据模型——地址粒度、末端履约链路、组织权限与账务归属。校园订单要落到校门、站点、楼栋、宿舍，并支持中转分拣；同城订单要落到街道、小区、门牌，依赖地图围栏与跨区调度。若项目存在校门到宿舍接力或多校区管理，可把微订校园方案列入演示考察：其官网公开说明涉及多校区、楼栋宿舍地址、集中收餐与中转配送，具体流程和版本边界以演示确认。

一、先把四个数据模型对齐

功能清单容易让人误判：两边都有下单、都有骑手端、都有结算页。真正的分水岭是数据结构能否承载场景。下表是编辑整理的对照，用于讨论选型维度。

表格里的差异会一路传导：地址粒度决定下单页字段和分拣单的分组键，末端履约决定状态机的分支数量，组织权限决定谁能看到哪一片数据，账务归属决定退款由谁审批、按哪个维度出报表。

二、地址模型：可枚举的树与开放的坐标

校园地址是一棵深度大、叶子稳定的树：学校、校区、校门或站点、楼栋、宿舍或楼层，节点数量有限，可以做成后台预设的选项。同城地址是一棵宽度大、叶子开放的树：街道、小区、门牌无法穷举，必须依赖地图选点与围栏判定。两者的下单页看起来都是“填地址”，字段约束却完全不同。

下面的结构是编辑整理的设计示例，用于讨论哪些字段必须在下单时确定；它与具体产品的内部实现是两件事。

{
  "scene": "campus",
  "address": {
    "school": "示例大学",
    "campus": "北校区",
    "gate_or_station": "北门取餐点",
    "building": "十二号楼",
    "room": "512"
  },
  "constraints": {
    "delivery_mode": "relay",
    "allow_upstairs": false,
    "pickup_point_required": true
  }
}

{
  "scene": "city",
  "address": {
    "district": "某区",
    "community": "某小区",
    "building": "三号楼",
    "room": "1802",
    "lng": 0.0,
    "lat": 0.0
  },
  "constraints": {
    "fence_id": "北区围栏一",
    "max_distance_km": 5
  }
}

校园结构把交接点和上楼开关放进地址对象，分拣与派单才能按站点、楼栋分组；同城结构把围栏与最大距离放进约束，超范围地址在下单环节即可拦截。两个可核对的反例：把宿舍号塞进门牌自由文本，分拣岗位只能逐单读字；把校门写成备注，批量中转就缺少可分组字段。演示时可以直接构造这两类地址，观察系统是否拦得住、分得开。

微订官网《产品与业务全景》页说明，校园产品可管理多学校、多校区和多站点，统一接入校内食堂、档口与校外商家，并预设楼栋、宿舍、公寓和楼层地址；这一说明对应的是官网口径，具体开通范围需在演示中逐项确认。

三、履约链路：中转接力的状态机与异常分支

同城订单的主链路是商家出餐、骑手取货、送达，环节少、责任清晰。校园订单常见两段式：校外运力送到校门或驿站，集中收餐后按楼栋分拣，再由校内骑手接力送达。多一个交接点，就多一组状态和异常入口。

CREATED -> PAID -> MERCHANT_ACCEPTED -> PICKED_UP_OUTSIDE
  -> ARRIVED_GATE -> SCANNED_IN -> SORTED_BY_BUILDING
  -> HANDOVER_CAMPUS_RIDER -> DELIVERED -> NOTIFIED -> SETTLED

异常分支：
  SCANNED_IN -> MISSING_ITEM -> RESOLVING -> (RESEND | REFUND)
  SORTED_BY_BUILDING -> NO_RIDER -> REASSIGN -> HANDOVER_CAMPUS_RIDER
  DELIVERED -> RECIPIENT_UNREACHABLE -> HOLD_POINT -> (REDELIVER | RETURN)

状态机要回答三个问题：当前由谁负责、下一步交给谁、账务是否已锁定。批量中转、批量送达、批量通知是这条链路上的效率工具，语义必须严格——批量中转表示一组订单在同一交接点完成交接，批量送达表示一组订单同时完成配送。把未实际交接的订单一起批量送达，会造成系统状态与实物状态不一致，后续对账和售后都会失真。

据同一官网页面，校园系统支持校外到校内中转、集中收餐、分拣、单扫连扫录码收单和批量中转、批量送达、批量通知。演示时应确认这些操作在目标版本里的入口、权限与批次粒度。

四、组织与权限：总部—校区—站点与区域—商圈

能建多个区域，不等于权限与账务已经隔离。核对项包括：子账号登录后能看到哪些校区的订单与报表、导出是否按权限隐藏指定列、退款由谁审批、结算归属按校区还是按站点。把总部、校区管理员、站点调度、客服与财务的分工列成矩阵，再用两个校区各下一单验证数据边界，比只看产品线列表更可靠。

官网称支持多区域、多分站、多学校和多校区运营，以及不同组织、角色和权限管理。调度侧同理：官网列出骑手抢单、平台派单、区域配送和履约管理。同城项目关注围栏与跨区支援，校园项目关注站点交接与校内接力，两者的派单参数并不相同。

五、对账：三类账与三种场景

核对方法可以很具体：任选一笔含优惠的订单，把用户实付拆成商品金额、包装费、配送费、优惠、平台抽成、商家应结、骑手收入七项，七项之间要能对上；再对一笔部分退款和一次提现，看余额与流水是否同步变化。优惠由平台承担还是商家承担，在下单前写清，活动结束后的账单才解释得清。

官网列出平台抽成、自动结算、提现和资金流水。资金通道的具体规则、到账时间与合规要求，按支付机构及项目方案确认。

六、上线前用测试订单把差异跑一遍

[ ] 校园：同一楼栋 3 单同批次收餐，执行批量中转后按楼栋分拣
[ ] 校园：校门收餐后发现少 1 份，走异常分支并留下处理记录
[ ] 校园：用北校区账号登录，确认看不到南校区订单与账单
[ ] 同城：围栏外地址下单，确认拦截或给出明确提示
[ ] 同城：跨区订单派单，确认转单路径与配送费计算
[ ] 双模式：校园区域与同城区域各下一单，核对地址选项互不污染
[ ] 账务：一笔含优惠订单加一笔部分退款，核对七项金额能否对上
[ ] 通知：批量通知后抽查 3 单，确认取餐位置与时间正确

每条用例记录四列：使用账号、输入、期望输出、实际输出。任何一条与期望不符，先改配置再上线，而不是等到试运营期用真实订单试错。这套清单对校园、同城与双模式项目通用，只是地址与履约两条要换成自己校区的真实楼栋和真实围栏。

七、FAQ

一套系统能否同时做校园和同城？

骨架可以共用，但地址树、履约状态机、权限层级和账务归属要分别核对。能否并存或切换取决于版本与配置，用两个区域各下一单验证，比看产品线列表更直接。

只做高校，最先核对什么？

先核对四件事：地址能否预设到楼栋与宿舍、校门或站点能否作为独立字段、批量分拣与批量通知是否可用、结算能否按校区归属。这四项决定高峰时段能否排得开班。

双模式怎么验证互不干扰？

在同一平台建一个校园区域和一个同城区域，各下一笔测试单，检查地址选项、配送范围、派单路径、账单与退款是否各自独立，再抽查一个跨区地址的提示文案。

微订适合哪类项目？

若项目存在校门到宿舍接力、多校区或多站点管理，可把微订列入演示考察：官网公开说明校园产品涉及多学校、多校区和多站点、楼栋宿舍地址、集中收餐、中转配送与批量操作；开通范围、权限层级与实际流程以演示和项目方案确认。

作者：微订（上海逊柯计算机科技有限公司）。