一套多租户的心理测评 SaaS，同一份程序、同一个数据库上同时住着上百所学校，每所学校看到的却应该只是属于自己的那一小块：自己的学生、自己的测评记录、自己采购的量表包。学校 A 花钱开通的量表，不该出现在学校 B 的可选列表里；学校 B 的学生数据，学校 A 更是一条都不该看到。这种“同住一栋楼、各锁各的门”的隔离，是多租户最基本、也最不能出错的地方。
隔离不是靠界面藏，而是靠查询带上租户
最不可靠的隔离，是数据混在一起、只在界面上按学校过滤——前端不显示不等于数据取不到，接口参数改一改就可能越界读到别人的。可靠的做法是让租户标识贯穿每一次数据访问：每一条学生、每一份作答、每一个量表授权记录都带着所属学校的标识，任何一次查询都强制带上“当前登录者属于哪所学校”这个条件，从数据层就把范围锁死。量表包同理，学校能用哪些量表，是一张“学校—量表授权”的关系记录，取可用量表列表时按当前学校去查，没授权的根本不进结果集，而不是全查出来再在页面上藏掉。橙星云的机构隔离就建在这条线上，每所学校的档案、测评和量表授权都按机构维度存取，一次查询只会落在自己的数据范围内。
最容易串的地方：共享的量表模板和跨校账号
真正容易串号的，多半是那些“看起来该共享”的东西。量表本身的题目和计分模板通常由平台统一维护、多校共用，共用的是量表的定义，但“哪所学校买了它、能不能发给学生用”必须按校隔离——把公共模板和按校授权分成两层，才不会因为模板共享就顺带让所有学校都能用。另一个高发点是跨校账号：一个心理老师同时服务几所学校，或平台运维要跨校排查问题，这类账号一旦不按“当前操作的是哪所学校”来收敛权限，就成了绕过隔离的口子。给这种账号的正确做法是显式切换当前所在的学校上下文，每次操作都明确落在一所学校范围内，而不是一登录就把名下所有学校的数据摊平在一起。
多租户隔离考验的从来不是某一个页面做没做过滤，而是从数据存储、每一次查询到跨校账号的权限收敛，是不是每一层都默认带着“这是哪所学校”。少带一层，隔离就在那一层破掉——而数据串号这种事，一次就足够让所有学校对这套系统失去信任。