摘要：多校区不是把学校字段加到每张表那么简单，它涉及租户、校区、组织权限和汇总口径。
为什么这个问题值得单独写
集团校或多校区项目中，管理者希望看到统一视图，校区又希望保持独立配置和数据边界。若模型设计不清，很容易出现校区数据串读、权限越界或统计口径不一致。
这类问题的麻烦之处在于，它通常不会在演示环境里暴露。演示只要一个班、一个按钮、一个屏幕就能跑通;真实学校会出现多批次、多角色、多校门、多终端、设备离线、家长通知失败和人工重置。技术架构如果没有提前留出边界，后续每增加一种学校规则，就会变成一次临时补丁。
设计原则
建议从 Tenant、School、Campus 三层理解：租户代表合同或集团边界，学校代表管理实体，校区代表具体场地和校门。不同项目可以合并层级，但概念上要分清。
对校园放学系统来说，架构设计首先要尊重现场流程：老师需要快，门岗需要确定，家长需要可理解，管理者需要可复盘。系统不应为了技术模型漂亮而增加现场负担，也不能为了短期上线把责任边界写得含糊。
模型拆分
权限也要分层。集团角色可以看汇总和配置模板，校级角色管理本校规则，校区角色处理本校区校门、屏幕和设备。跨校区操作应有显式授权。
这一步最容易被忽略。很多系统不是没有表，也不是没有接口，而是核心概念没有拆清楚。只要核心概念混在一起，后面就会出现页面字段越来越多、接口参数越来越长、设备接入越来越难测的问题。
数据与接口示意
统计汇总不能简单相加。不同校区的放学时段、批次和设备组合不同，汇总指标要有口径说明。
示意结构里的字段不要求照搬。真正落地时，更重要的是确认字段背后的责任：谁创建，谁修改，谁消费，谁能看到，出了错谁来复核。字段的业务解释比字段名本身更重要。
异常与失败路径
失败场景包括共享账号跨校区操作、模板配置误覆盖、设备归属错误、集团统计把不同口径混在一起。每个接口都要带租户和校区上下文。
放学系统不适合只设计成功路径。现场人员最需要系统帮忙的时候，往往就是网络不稳、设备不在线、家长没到、重复点击或人工误操作的时候。异常路径如果没有进入主流程，就会退回到微信群、口头交接和纸面登记。
分阶段落地方式
第一阶段建议先做流程澄清，不急着把所有终端和设备一次性接入。以“任务是否能生成、状态是否能被授权角色推进、异常是否能被记录”为最低闭环，先让学校确认这套模型能解释真实放学流程。这个阶段的价值，是把讨论从“买哪个设备”拉回“现场到底怎么协同”。
第二阶段再接入展示和通知。大屏、语音、家长通知、小程序消息等能力都应消费核心事件，而不是重新计算状态。这样做的好处是，当通知渠道失败或大屏离线时，核心任务仍然可用，现场人员也能知道问题发生在输出层，而不是业务本身。
第三阶段才适合考虑设备联动、跨校区汇总、增强审计或更复杂的离线补传。复杂能力越靠后，越需要前两阶段留下清晰的任务模型、权限模型和事件记录。否则后续每一次扩展都会变成补丁叠补丁。
架构评审问题
●这个设计里，多校区架构：租户、校区、权限与数据隔离如何组织对应的业务事实由哪一层负责写入?
●如果现场网络、设备或通知渠道失败，流程是否还能给出可执行结果?
●如果同一动作被重复提交，系统如何判断是重试、并发还是冲突?
●如果学校规则下个月变化，是否只改配置或适配层，而不是改核心流程?
●这个设计在试点验收时，学校、教师、门岗和技术实施方分别需要看到哪些证据?
测试与验收建议
测试应覆盖跨租户不可见、同租户跨校区受控、模板下发、校区独立调整、设备迁移和汇总权限。
验收不要只看页面是否美观，也不要只看接口是否返回成功。更好的办法是构造完整场景：任务生成、权限校验、状态迁移、设备事件、通知、大屏、语音、日志和日终复盘都跑一遍。只要其中任何一环说不清，系统就还没有真正进入可运营状态。
一个比较实用的验收方式，是把“正常路径、重复路径、失败路径、恢复路径”写成四组用例。正常路径证明功能可用，重复路径证明幂等和状态机可靠，失败路径证明异常可见，恢复路径证明系统不是一次性演示工具。对于学校项目来说，能恢复、能解释、能复盘，往往比单次成功更重要。
写在最后
校园放学系统看起来是一个垂直场景，但它背后包含领域建模、权限、状态机、消息、设备、部署、测试和可观测性。把这些问题拆开写，不是为了把系统讲复杂，而是为了让学校和集成伙伴知道：可视化放学不是堆硬件，也不是多发通知，而是一套需要持续治理的现场协同系统。
相关阅读：RBAC、私有部署、日志验收。