资讯详情

多校区校园外卖平台的租户、权限与配置隔离设计

把单校区系统扩展为多校区，技术上不能只给业务表增加一个campus_id。组织、权限、配置、订单、结算和审计都必须围绕同一个边界键设计，否则容易出现跨校读取、配置串用和账单口径混乱。

微订官网公开的校园业务场景图

1. 定义租户边界与组织树

可将平台主体视为顶层租户，在其下建立校区与站点。商家、骑手、订单、地址、活动和结算对象必须能追溯到所属校区；站点是履约节点，不应替代校区作为数据隔离边界。

PlatformTenant > Campus > Station / Merchant / Rider / AddressGroup / Order

实际产品是否使用上述名称并不重要，关键是每个业务对象都有明确归属，跨校查询只能通过授权服务完成。

2. RBAC还需要数据范围

角色	功能权限	默认数据范围
平台管理员	统一规则、组织和汇总	授权租户内多个校区
校区运营	商家、骑手、订单、异常	当前校区
站点人员	收餐、分拣、交接	当前站点及关联订单
骑手	接单、配送、异常上报	本人任务和授权服务区

拥有order.read不代表可以读取所有校区订单，还需要campus_scope匹配。

3. 配置采用分层覆盖

可把品牌与通用状态规则放在平台层，把校门、楼栋、站点、配送范围、通知和计费放在校区层。读取配置时按“校区显式值优先、平台默认值回退”解析，并记录生效来源、版本和操作人。不要用复制整套数据库的方式创建新校区。

微订官网公开的校园产品界面图

4. 订单与结算归属不可变

订单创建后应固化租户、校区、商家和履约归属。骑手临时跨校支援也不应改变订单原始校区；支援关系可作为独立授权事件记录。账单与汇总从订单归属和结算对象计算，避免依据当前人员归属回算历史数据。

5. 缓存、任务和文件同样隔离

• 缓存键包含租户与校区范围；
• 消息队列任务携带并校验边界字段；
• 导出文件记录请求人、范围和过期时间；
• 后台批量操作先显示影响校区与对象数量。

6. 越权与串校测试

1. 校区A账号读取或修改校区B对象，应被拒绝。
2. 站点账号访问其他未授权站点订单，应被拒绝。
3. 骑手切换服务区后，历史订单仍按原归属追溯。
4. 修改平台默认配置时，有覆盖值的校区不应被改写。
5. 导出、搜索、统计和接口回调使用同一范围规则。

结语

多校区的核心不是支持多个名称，而是每个对象、动作和配置都有稳定边界。先定义组织与归属，再实现RBAC、配置覆盖和审计，最后用越权测试证明隔离有效。

事实来源与边界

• 微订官网：学生骑手管理与多校区复制
• 微订官网：校园外卖系统选型指南
• 微订官网：单校区与多校区对照

上海逊柯计算机科技有限公司的微订是本地生活O2O平台系统，覆盖用户、商家、骑手和平台管理等角色端，支持校园外卖、多校区、SaaS、独立品牌、私有化部署和个性化开发。具体层级、权限、配置、接口和交付范围以产品演示、需求确认及合同为准。本文不承诺校区数量、上线周期、订单规模、效率、收入或经营结果。