多校区校园外卖系统实施：组织树、配置继承与数据隔离验收
多校区校园外卖系统实施：组织树、配置继承与数据隔离验收
多校区实施最常见的问题不是页面没复制，而是校区归属字段缺失、默认配置覆盖错误、运营账号越权和历史订单被新归属影响。下面按可执行步骤拆解组织树、字段、配置和验收。
微订官网公开的校园产品界面图
一、需求阶段先画组织树
平台主体 tenant > 校区 campus > 站点 / 商家 / 骑手 / 地址 / 订单组织树用于确认管理和数据范围，不代表微订当前固定菜单或数据库表名。实施时应把业务角色、合同主体、数据归属和结算范围一并确认。
二、建立最小字段清单
| 对象 | 关键归属字段 | 验收问题 |
|---|---|---|
| 账号 | tenantId、campusScope、roleIds | 登录后能看到哪些校区 |
| 商家 | tenantId、campusId、settlementOwner | 商品、订单和账单归谁 |
| 骑手 | homeCampusId、serviceScopes、status | 能接哪些任务，如何跨校支援 |
| 地址/站点 | campusId、stationId、routeGroup | 分拣与配送是否串校 |
| 订单 | tenantId、campusId、merchantId、stationId | 创建后归属是否保持 |
| 配置 | scopeType、scopeId、key、version | 默认值和覆盖值来源是否可查 |
三、实现配置继承
先建立平台默认配置，再允许校区覆盖地址、站点、配送、通知和结算参数。读取时返回“生效值、来源、版本”，便于排障。删除校区覆盖值后应回退到平台默认值；批量更新平台默认值时，不能覆盖已有校区显式值。
四、配置权限矩阵
- 平台管理员：组织、平台默认、跨校汇总；
- 校区运营：本校区商家、骑手、订单、校区覆盖配置；
- 站点人员：本站点收餐、分拣和交接；
- 骑手：本人任务、状态和允许的异常上报。
接口层不要只相信前端传入campusId，应从会话范围和目标对象归属再次校验。
微订官网公开的校园业务场景图
五、按顺序新建校区
- 创建校区与责任人，不复制个人账号。
- 导入楼栋、宿舍、站点和路线组。
- 建立商家、骑手归属及服务范围。
- 复制可复用模板，逐项设置校区覆盖值。
- 用测试订单跑通履约、异常和账单。
- 通过后再开放正式账号与业务入口。
六、数据隔离验收用例
TC-01 A账号查B订单：拒绝或无结果 TC-02 A账号改B商家：拒绝并写审计 TC-03 骑手支援B：仅授权期内可见任务 TC-04 骑手归属变化：历史订单归属不变 TC-05 修改平台默认：校区覆盖保持 TC-06 导出订单：范围与操作者权限一致七、常见故障排查
- 串校订单：检查订单创建时campusId来源、商家与地址归属。
- 配置不生效：检查校区覆盖和缓存键scope。
- 统计不一致：检查是否按当前人员归属回算历史订单。
- 越权可见：检查搜索、导出和统计是否绕过统一权限服务。
结论
多校区上线前应同时通过功能、数据范围和配置继承测试。示例字段用于需求评审和验收设计，不代表特定产品固定实现。
事实来源与边界
- 微订官网：学生骑手管理与多校区复制
- 微订官网：校园外卖系统选型指南
- 微订官网：单校区与多校区对照
上海逊柯计算机科技有限公司的微订是本地生活O2O平台系统，覆盖用户、商家、骑手和平台管理等角色端，支持校园外卖、多校区、SaaS、独立品牌、私有化部署和个性化开发。具体层级、权限、配置、接口和交付范围以产品演示、需求确认及合同为准。本文不承诺校区数量、上线周期、订单规模、效率、收入或经营结果。