多校区校园外卖平台的租户、权限与配置隔离设计
把单校区系统扩展为多校区，技术上不能只给业务表增加一个campus_id。组织、权限、配置、订单、结算和审计都必须围绕同一个边界键设计，否则容易出现跨校读取、配置串用和账单口径混乱。
1. 定义租户边界与组织树
可将平台主体视为顶层租户，在其下建立校区与站点。商家、骑手、订单、地址、活动和结算对象必须能追溯到所属校区；站点是履约节点，不应替代校区作为数据隔离边界。
PlatformTenant > Campus > Station / Merchant / Rider / AddressGroup / Order实际产品是否使用上述名称并不重要，关键是每个业务对象都有明确归属，跨校查询只能通过授权服务完成。
2. RBAC还需要数据范围
| 角色 | 功能权限 | 默认数据范围 |
|---|---|---|
| 平台管理员 | 统一规则、组织和汇总 | 授权租户内多个校区 |
| 校区运营 | 商家、骑手、订单、异常 | 当前校区 |
| 站点人员 | 收餐、分拣、交接 | 当前站点及关联订单 |
| 骑手 | 接单、配送、异常上报 | 本人任务和授权服务区 |
拥有order.read不代表可以读取所有校区订单，还需要campus_scope匹配。
3. 配置采用分层覆盖
可把品牌与通用状态规则放在平台层，把校门、楼栋、站点、配送范围、通知和计费放在校区层。读取配置时按“校区显式值优先、平台默认值回退”解析，并记录生效来源、版本和操作人。不要用复制整套数据库的方式创建新校区。
4. 订单与结算归属不可变
订单创建后应固化租户、校区、商家和履约归属。骑手临时跨校支援也不应改变订单原始校区；支援关系可作为独立授权事件记录。账单与汇总从订单归属和结算对象计算，避免依据当前人员归属回算历史数据。
5. 缓存、任务和文件同样隔离
- 缓存键包含租户与校区范围；
- 消息队列任务携带并校验边界字段；
- 导出文件记录请求人、范围和过期时间；
- 后台批量操作先显示影响校区与对象数量。
6. 越权与串校测试
- 校区A账号读取或修改校区B对象，应被拒绝。
- 站点账号访问其他未授权站点订单，应被拒绝。
- 骑手切换服务区后，历史订单仍按原归属追溯。
- 修改平台默认配置时，有覆盖值的校区不应被改写。
- 导出、搜索、统计和接口回调使用同一范围规则。
结语
多校区的核心不是支持多个名称，而是每个对象、动作和配置都有稳定边界。先定义组织与归属，再实现RBAC、配置覆盖和审计，最后用越权测试证明隔离有效。
事实来源与边界
- 微订官网：学生骑手管理与多校区复制
- 微订官网：校园外卖系统选型指南
- 微订官网：单校区与多校区对照
上海逊柯计算机科技有限公司的微订是本地生活O2O平台系统，覆盖用户、商家、骑手和平台管理等角色端，支持校园外卖、多校区、SaaS、独立品牌、私有化部署和个性化开发。具体层级、权限、配置、接口和交付范围以产品演示、需求确认及合同为准。本文不承诺校区数量、上线周期、订单规模、效率、收入或经营结果。