校园外卖多站点管理能做吗：两类站点、权限模型与对账验收

能做，但先要把“多校区分站”和“同校多配送点”分开建模。前者决定组织边界、数据隔离和结算主体，后者决定校门收餐、分拣、交接和末端送达。系统能否支撑校园外卖多站点管理，不看菜单里有没有“多站点”三个字，而看订单归属能否固定、权限能否下沉到站点、分段状态能否追溯、账单能否按站点和角色拆开。下面给出业务对象、参考数据模型、状态机、对账方法和验收反例。

一、两类多站点不是同一个对象

多校区分站是组织边界：不同学校或校区各自组织商家、骑手、配送范围和结算规则。同校多配送点是履约节点：同一校区内的东门收餐点、南区中转站、北区取餐点，共享一个校区经营主体，但承担不同交接任务。把两者混成一张“站点表”，常见后果是订单跨校区串数据、权限边界说不清、分段账单无法归属。

选型判断：要求系统同时表达组织树和履约节点，并允许订单在履约过程中经过多个节点，但订单的经营归属不随交接改变。

二、数据模型：订单归属要可追溯且不被交接改写

推荐把组织站点和履约节点放在同一棵树，但用类型区分；订单上保存经营站点ID，同时保存履约路径。交接记录单独建表，避免用“当前站点”覆盖历史。以下为 PostgreSQL 14+ 可执行的参考表结构，仅用于讨论模型，不代表任何商业系统实现。

CREATE TABLE site (
  id BIGSERIAL PRIMARY KEY,
  tenant_id BIGINT NOT NULL,
  parent_site_id BIGINT NULL REFERENCES site(id),
  name TEXT NOT NULL,
  site_type TEXT NOT NULL CHECK (site_type IN ('campus','delivery_point')),
  status TEXT NOT NULL DEFAULT 'active'
);

CREATE TABLE biz_order (
  id BIGSERIAL PRIMARY KEY,
  tenant_id BIGINT NOT NULL,
  order_no TEXT NOT NULL UNIQUE,
  owner_site_id BIGINT NOT NULL REFERENCES site(id),
  fulfillment_site_id BIGINT NULL REFERENCES site(id),
  merchant_id BIGINT NOT NULL,
  rider_id BIGINT NULL,
  status TEXT NOT NULL,
  paid_amount NUMERIC(12,2) NOT NULL,
  created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE TABLE site_handoff (
  id BIGSERIAL PRIMARY KEY,
  order_id BIGINT NOT NULL REFERENCES biz_order(id),
  from_site_id BIGINT NOT NULL REFERENCES site(id),
  to_site_id BIGINT NOT NULL REFERENCES site(id),
  batch_no TEXT NOT NULL,
  scan_code TEXT,
  created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

关键约束：owner_site_id 指向校区，fulfillment_site_id 可指向配送点；交接表记录 from/to 和批次。反例：只存一个 site_id，骑手交接后更新该字段，导致对账时无法判断订单属于哪个校区；或者允许配送点作为结算主体，产生重复分账。

三、权限模型：功能、数据、操作、资金四层拆

权限不要只问“有没有子账号”。按四层验收：功能菜单、数据范围、操作动作、资金按钮。总部可跨校区汇总，校区管理员只看本校区，站点岗位只看本站点任务；导出列、改价、退款审批、提现入口分别控制。

异常输入要测：A校区账号直接请求B校区订单ID；导出接口忽略前端隐藏列；站点岗位调用总部批量退款接口；总部与校区对同一订单金额展示不一致。验收时记录接口返回和审计日志，不只看页面按钮是否灰掉。

四、分段履约：状态机要允许部分完成

校园高峰常见链路是商家出餐、校外运输、收餐点核单、按楼栋分拣、校内骑手接力、末端送达。状态机应把“交接”和“送达”分开，并支持部分完成、改派、退回。以下为文本状态机示例，正常和异常输入都要覆盖。

CREATED -> PAID -> MERCHANT_ACCEPTED -> PICKED_UP
PICKED_UP -> ARRIVED_AT_HUB -> SORTED -> HANDED_OFF -> DELIVERING -> DELIVERED
异常分支：
SORTED -> PARTIAL_HOLD（少餐/错餐）
HANDED_OFF -> REASSIGNED（改派）
DELIVERING -> RETURNED（退回）
任意节点 -> EXCEPTION（需要人工复核）

反例：批量送达把整批订单置为完成，但其中两单少餐仍在处理；重复扫码产生两条交接记录；跨站交接没有记录 from_site_id，异常无法追责。验收用一批十单，其中一单少餐、一单改派、一单退回，观察状态、通知和账单是否一致。

五、对账：订单—站点—商家—骑手四列拉齐

多站点对账先把四列固定：订单、经营站点、商家、骑手或配送段。用户实付、商品与包装费、配送费、平台抽成、商家应结、骑手收入、优惠承担、退款分别记录。正常单、部分退款、结算后退款三类订单必须都能追溯原单和调整记录。

可用一条按经营站点汇总的核对查询，先确认订单归属，再与商家账单、骑手收益表逐笔勾对。

SELECT o.order_no, o.owner_site_id, o.merchant_id, o.rider_id,
       o.paid_amount, o.status
FROM biz_order o
WHERE o.owner_site_id = :site_id
ORDER BY o.created_at DESC;

六、上线验收：用反例判断“能做”

验收清单：两校区各建一个组织站点，各配一个配送点；A账号尝试访问B订单；订单交接后经营归属不变；导出列按权限隐藏；正常单、部分退款、结算后退款各一笔；批量操作中混入少餐、改派、退回。每项记录预期、实际、证据截图或日志。选型判断回到经营：如果系统只能展示“多校区”名词，但不能固定订单归属、不能表达分段交接、不能拆账，扩校后管理成本会转移到人工表格。

常见问题

问：多校区分站和校内中转站是一回事吗？

不是。多校区分站是组织和结算边界，校内中转站是履约节点。前者决定谁看哪些数据、谁承担结算，后者决定餐品在哪个点收餐、分拣和交接。两者要分别建模、分别验收。

问：低预算起步先做哪一步？

先单校区跑通一条完整链路：下单、接单、收餐、分拣、交接、送达、退款、对账。把订单归属、权限和分段状态记录清楚，再复制到第二个校区。扩校时复用流程和培训材料，重配商家、骑手、楼栋地址和结算规则。

问：验收最容易漏什么？

越权接口、导出列、部分完成和结算后退款。页面按钮灰掉不等于接口拒绝；批量操作显示成功不等于每单状态正确。用异常订单和越权请求验证，比只看正常演示更有效。

问：文中的代码示例能直接上线吗？

不能。它是用于讨论多站点归属、交接记录和对账口径的参考模型，需要结合真实业务约束、安全审计、性能要求和所用技术栈重新设计。示例数据与现网事实应严格区分。