身份边界矩阵
这页解决什么问题
LuckyColor 里最常见的三类身份是：
- 平台管理员
- 租户管理员
- 普通成员
大家在讨论权限时，经常会混着说“角色”“身份”“边界”“菜单”“按钮”，结果最后谁能做什么并不清楚。
这页专门回答一个更实际的问题：
- 默认情况下，这三类身份分别应该管到哪里，止步于哪里
先说结论
可以先把三类身份理解成三种默认视角：
| 身份 | 默认视角 | 一句话理解 |
|---|---|---|
| 平台管理员 | 平台视角 | 管租户，也能看平台级配置与租户内核心管理能力 |
| 租户管理员 | 当前租户视角 | 只在本租户内做组织、账号、角色、菜单等日常管理 |
| 普通成员 | 个人使用视角 | 主要使用系统，不负责管理平台或租户 |
一个很重要的前提
这页讲的是“默认边界矩阵”，不是“永远固定死的硬编码规则”。
真实系统里，最终权限仍然取决于：
- 当前用户绑定了哪些角色
- 这些角色拿到了哪些菜单
- 这些角色拿到了哪些按钮权限
- 这些角色的数据范围是什么
- 当前租户状态是否允许访问
所以这页适合拿来做：
- 团队沟通口径
- 默认角色设计说明
- 排查“这个人为什么不该看到这里”的参考
三类身份的默认边界矩阵
总表
| 能力域 | 平台管理员 | 租户管理员 | 普通成员 |
|---|---|---|---|
| 登录系统 | 可以 | 可以 | 可以 |
| 查看工作台 | 可以 | 可以 | 可以 |
| 查看当前用户资料 | 可以 | 可以 | 可以 |
| 查看当前租户内基础菜单 | 可以 | 可以 | 可按授权查看 |
| 管理租户列表 | 可以 | 不应默认开放 | 不应开放 |
| 创建 / 更新租户 | 可以 | 不应默认开放 | 不应开放 |
| 管理租户套餐 | 可以 | 不应默认开放 | 不应开放 |
| 将套餐绑定到租户 | 可以 | 不应默认开放 | 不应开放 |
| 管理当前租户用户 | 可以 | 可以 | 不应默认开放 |
| 给用户分配角色 | 可以 | 可以 | 不应开放 |
| 管理当前租户角色 | 可以 | 可以 | 不应默认开放 |
| 配置角色菜单 / 数据权限 | 可以 | 可以 | 不应开放 |
| 管理当前租户部门 | 可以 | 可以 | 不应默认开放 |
| 管理当前租户菜单 | 可以 | 可以 | 不应开放 |
| 管理字典 / 配置 / 公告 | 可以 | 常见可开放 | 不应默认开放 |
| 查看或修改本人偏好 | 可以 | 可以 | 可以 |
| 上传业务文件 | 可按页面授权 | 可按页面授权 | 可按页面授权 |
| 查看系统日志 | 常见可开放 | 视租户治理要求而定 | 不应开放 |
分模块理解会更直观
1. 平台级能力
平台级能力最典型的就是：
- 租户管理
- 租户套餐
- 平台级运营视角
这些能力默认应该只给平台管理员。
原因很简单：
- 它们影响的不是一个租户，而是整个平台的租户开通和运营边界
2. 租户内治理能力
租户内治理通常包括：
- 用户管理
- 角色管理
- 部门管理
- 菜单管理
- 配置、公告、字典等租户内管理页
这些能力默认更适合：
- 平台管理员
- 租户管理员
普通成员一般不承担治理职责，所以不应默认开放。
3. 个人使用能力
个人使用能力更接近：
- 登录
- 看工作台
- 查看自己能访问的菜单
- 修改自己的偏好设置
- 在被授权页面中完成业务操作
这部分普通成员通常可以拥有，但范围仍要看具体页面授权。
分身份展开说明
平台管理员
默认定位
平台管理员是平台运营和平台治理身份，典型角色编码是：
super_admin
默认应该能做什么
- 管理租户
- 管理租户套餐
- 查看和调整平台级系统能力
- 进入租户内核心管理模块
- 看到完整或接近完整的数据范围
默认不该忽略什么风险
平台管理员虽然边界最大，但也最需要注意：
- 不能把“平台管理员”误当成所有页面永久绕过逻辑
- 涉及租户切换、租户冻结、租户过期时仍要受租户状态校验
- 关键操作最好保留系统日志和安全审计
租户管理员
默认定位
租户管理员负责当前租户的日常治理，典型角色编码是：
tenant_admin
默认应该能做什么
- 管理本租户用户
- 管理本租户角色
- 管理本租户部门
- 管理本租户菜单
- 维护字典、配置、公告等租户内后台能力
默认不应该碰什么
租户管理员默认不应越过租户边界，通常不应直接拥有：
- 平台租户列表管理权
- 新建 / 修改其他租户的能力
- 租户套餐平台级运营能力
最容易混淆的一点
“租户管理员权限很大”不等于“租户管理员就是平台管理员”。
它的大，是在当前租户内部大，而不是对全平台大。
普通成员
默认定位
普通成员是系统使用者，典型角色编码是：
tenant_member
默认应该能做什么
- 登录
- 看自己有权访问的页面
- 使用工作台
- 处理个人相关操作
- 在授权范围内查看自己的数据或本部门数据
默认不应该做什么
普通成员默认不应承担系统治理动作，例如：
- 管用户
- 管角色
- 管菜单
- 管部门
- 管租户
- 管套餐
数据范围通常更小
普通成员最常见的数据范围是：
SELF
也就是更偏“只能看本人相关数据”。
为什么同样是管理员，还要区分平台和租户两层
因为这两层解决的是不同问题。
平台管理员关心
- 平台上有哪些租户
- 每个租户用哪个套餐
- 哪些租户启用、冻结、过期
租户管理员关心
- 当前租户有哪些用户
- 当前租户角色怎么授权
- 当前租户部门怎么维护
如果不分这两层，就很容易把 SaaS 平台做成“所有管理员都能碰所有租户”的高风险结构。
边界矩阵和菜单 / 按钮 / 数据权限是什么关系
这三者不是互斥关系，而是从粗到细的三层。
第一层：边界矩阵
回答的是：
- 某类身份默认应该进入哪些能力域
第二层：菜单权限
回答的是：
- 这个人能不能看到某个模块、某个页面
第三层：按钮权限与数据权限
回答的是：
- 这个人能不能点击某个动作
- 即使进了页面，能看到多大范围的数据
所以边界矩阵更像：
- 权限设计的顶层口径
而菜单、按钮、数据权限是：
- 真正落到代码和数据库里的执行层
排查问题时怎么用这张矩阵
场景 1：租户管理员看到了租户中心
优先怀疑：
- 是否误授予了平台级菜单
- 是否把平台级按钮权限给到了租户管理员
- 是否前端菜单过滤口径和后端权限口径不一致
场景 2：普通成员能修改用户或角色
优先怀疑：
- 角色菜单授权是否超出预期
- 按钮权限码是否分配过多
- 页面是否漏加权限控制
- 后端控制器是否漏加权限装饰器
场景 3：平台管理员反而进不去某些租户内页面
优先怀疑：
- 当前租户上下文是否正确
- 租户是否禁用、冻结或过期
- 平台管理员是否真的拿到了对应菜单或按钮权限
- 当前页面是否叠加了租户内数据范围限制
推荐的团队使用方式
如果你们后续要继续扩展 LuckyColor，我建议把这页当成：
- 默认角色设计说明
- 权限评审 checklist
- 新页面菜单与按钮授权的参考基线
新增管理页面时，先问三个问题：
- 这是平台级能力，还是租户级能力
- 租户管理员是否应该默认拥有
- 普通成员是否应该只看结果、不做治理