同城生活服务小程序：外卖+跑腿一站式架构与异常验收

直接答案：同城生活服务小程序开发，先把问题拆成四端、两条订单流和三类账，而不是先做首页和功能清单。用户端下单，商家端接单出餐，骑手端取送交接，平台端管区域、权限、订单、资金和售后；外卖订单有商家，跑腿任务没有商家，二者可共用地址和骑手池，但计价、结算、售后必须分开。校园项目还要补校门交接、集中收餐、楼栋分拣、批量操作和多校区权限。下面给出数据结构、状态机、异常验收和部署选型方法。

一、四端与两条订单流：先定边界，再谈功能

一站式平台容易做成功能堆叠，根因是角色和订单类型没有拆清。用户端负责选商家或发跑腿任务，商家端负责接单、出餐和售后，骑手端负责取送、交接和凭证，平台端负责区域、商家、骑手、权限、资金和对账。四端不是四套孤立页面，而是围绕同一订单号交换状态和金额。

订单流要分两类。外卖订单有商家、商品和出餐时间，结算对象是商家与骑手；跑腿任务没有商家，核心是起点、终点、物品说明、取送凭证和服务费，结算对象是骑手与平台。两类订单可以共用用户、地址、区域和骑手池，但订单类型、计价规则、结算单和售后记录要分开，否则退款和分账会互相污染。

二、状态机与三类账：用订单、结算、退款串起来

订单状态机先写主路径，再写异常路径。主路径只允许按顺序推进，异常路径必须从明确状态进入，并保留操作人、时间和原因。下面为设计示例，不代表任何产品的内部实现。

外卖：CREATED -> PAID -> MERCHANT_ACCEPTED -> PREPARING
      -> RIDER_ASSIGNED -> PICKED_UP -> DELIVERED
      -> CONFIRMED -> SETTLED

跑腿：CREATED -> PAID -> PUBLISHED -> RIDER_ACCEPTED
      -> PICKED_UP -> DELIVERED -> CONFIRMED -> SETTLED

异常：PAID / MERCHANT_ACCEPTED / PREPARING / DELIVERED
      -> REFUNDING -> REFUNDED

状态机落地时，每次变更都要校验当前状态。例如订单未支付不能接单，未取餐不能送达，已结算的退款要生成冲回记录。支付回调、批量送达和退款申请要使用幂等键，避免重复请求生成两笔结算或两次退款。

三类账分别回答三个问题：订单账记录用户实付、优惠、配送费、平台抽成、商家应结和骑手收入；结算账记录谁在什么时间、按什么规则、结算多少；退款账记录退哪笔订单、冲回哪笔结算、由谁承担。三张表通过订单号关联，金额变化保留原订单和处理原因。

下面给出表结构示例，重点是可追溯和幂等，不是要求照搬字段。

-- 设计示例，不是产品内部实现
CREATE TABLE biz_order (
  order_no      VARCHAR(32) PRIMARY KEY,
  order_type    VARCHAR(16) NOT NULL,
  merchant_id   VARCHAR(32),
  status        VARCHAR(24) NOT NULL,
  user_paid     DECIMAL(10,2) NOT NULL,
  refunded      DECIMAL(10,2) NOT NULL DEFAULT 0
);

CREATE TABLE settlement (
  settlement_no VARCHAR(32) PRIMARY KEY,
  order_no      VARCHAR(32) NOT NULL,
  party_type    VARCHAR(16) NOT NULL,
  amount        DECIMAL(10,2) NOT NULL,
  status        VARCHAR(16) NOT NULL,
  idem_key      VARCHAR(64) NOT NULL UNIQUE
);

CREATE TABLE refund_bill (
  refund_no     VARCHAR(32) PRIMARY KEY,
  order_no      VARCHAR(32) NOT NULL,
  settlement_no VARCHAR(32),
  amount        DECIMAL(10,2) NOT NULL,
  status        VARCHAR(16) NOT NULL
);

三、校园场景：校门、楼栋、批量与多校区怎么落到数据

校园外卖系统与普通同城外卖的差异在末端履约。普通订单送到地址即可，校园订单常要经过校门核单、集中收餐、按楼栋分拣、校内接力和送达通知。数据模型要增加校区、校门、站点、楼栋、交接批次和配送任务，让订单能回答三个问题：现在在谁手里、下一手是谁、异常由谁接续。

推荐流程是：商家出餐，校外运输，校门核单，按楼栋分拣，校内接力，送达通知。高峰时再启用批量中转、批量送达和批量通知。批量操作只处理已确认选中的订单，部分完成时其余订单必须保留原状态，不能因为一次批量点击全部改成已送达。

多校区权限按角色、校区、站点和数据范围配置。订单、商家、骑手、楼栋地址和结算单都带校区归属；总部看汇总，校区管理员看本校，站点看本站，财务和客服按岗位查看必要字段。导出功能尤其要核对：同一报表在不同子账号下，可见列和可导出列是否一致。

四、部署、预算与合规：技术选型要写进合同

部署方式按数据控制、技术团队、维护责任和上线节奏选择。SaaS适合快速启动和轻技术团队，私有化适合对环境和数据管理有明确要求的项目，源码适合有持续开发能力的团队，定制适合标准流程无法覆盖的接口或规则。四种方式都要把模块、终端、账号主体、升级维护和验收标准写进交付清单。

预算不要只问一个总价，要拆成软件套餐、增值模块、部署环境、第三方服务、定制开发、培训与持续维护，并分别确认一次性费用和续费。地图、短信、支付、云资源等第三方服务按实际用量或通道规则计费。历史成交价只能作为带时间、模块和交付内容的案例，不能当成当前统一报价。

合规按业务实质核对。平台代收资金、撮合交易、分佣和分账时，要核对支付通道、商户主体、结算账户、当地监管要求和合同责任；涉及EDI等许可时，以主管部门和当地要求为准。餐饮商家要核验食品经营资质并留入驻审核记录，骑手保障、隐私号、个人信息和导出权限也要有对应流程。

五、把方案变成验收：一笔订单加五类异常

演示前准备校区数量、校门位置、楼栋清单、通行时段、商家来源、配送分工和退款场景。演示时用一笔正常订单走完下单、支付、接单、出餐、校门交接、楼栋分拣、送达和结算，再用五类异常检查系统是否接得住。

1. 缺货：商家少做商品，查看部分退款、补送和商家应结是否同步调整。
2. 错餐：分拣后发现错配，查看原订单、当前负责人、处理动作和结果是否留痕。
3. 无人接手：学生暂时联系不上，查看暂存、改约、退回和费用规则是否清楚。
4. 退款冲回：已结算订单退款，查看退款账是否关联原结算并生成冲回。
5. 越权访问：用校区账号查其他校区，查看数据范围和导出字段是否被限制。

验收记录至少包含账号、步骤、订单状态、金额变化、责任人和证据截图。通过标准不是页面好看，而是状态、金额、权限三者一致：订单在谁手里可查，金额从支付到结算到退款可追，不同角色只能看该看的数据。示例状态机、表结构和验收清单属于设计方法，运行结果以实际演示环境和验证记录为准。

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