角色层次与继承关系：如何设计层级角色及权限传递规则
权限继承，说白了就是让上级角色“自带”下级角色的权限。我刚开始接触RBAC时，觉得这设计挺简单——父角色有的权限，子角色自然也有。结果第一次上线就踩了坑：一个CEO角色继承了所有部门经理的权限，连工资表的编辑权都带上了。嗯，从那以后我才认真研究起角色层次的设计。
角色层次不是简单的一棵树，它涉及权限的“方向”和“粒度”。你想想看，如果所有管理岗都继承操作岗的全部权限，那审计岗就麻烦了——查操作日志时，谁改了数据根本分不清。今天我就把这几年的经验拆开讲讲。
层级角色的设计原则
我习惯先画一张角色关系图，再动手写配置。角色层次通常分三种结构：
- 树形继承：一个父角色可以有多个子角色，但子角色只有一个父角色。适合组织架构清晰的系统。
- 网状继承：一个子角色可从多个父角色继承权限。适合跨部门协作场景，但也容易搞出权限膨胀。
- 层级限制继承：只允许相邻层级继承，跨级需要显式授权。我一般用这种来防止权限“穿层”。
我在项目中遇到过最头疼的就是网状继承。有一次，一个“项目经理”角色同时继承了“开发主管”和“运维主管”的权限，结果项目经理不小心删掉了生产数据库的备份任务。所以现在我有个硬性要求：任何多继承都必须单独审计。
权限传递规则：四种模式
权限怎么从父角色传到子角色？不同公司规则不一样。我把常见的整理成一张表：
| 传递模式 | 含义 | 典型场景 | 我踩过的坑 |
|---|---|---|---|
| 全部继承 | 子角色自动获得父角色的所有权限 | 默认设置，适合简单层次 | 权限冗余，子角色能做的事远超预期 |
| 选择性继承 | 父角色指定哪些权限可继承 | 敏感权限需显式声明 | 配置复杂，容易遗漏 |
| 向上传递 | 子角色权限自动也归父角色拥有 | 审计汇总场景 | 逆向继承导致权限循环 |
| 隔层阻断 | 跨级父角色不继承孙子角色的权限 | 防止权限“直升” | 策略明确但实现麻烦 |
我个人习惯采用“全部继承 + 隔层阻断”的组合。子角色无条件拥有父角色权限，但爷爷角色不能直接拿到孙子角色的权限。这样既能保证继承链条清晰，又能避免管理层权限过大。
核心原则：
继承传递必须遵循最小权限+显式继承。任何未显式声明的继承都默认拒绝。
权限传递的代码示例
假设我们用一个简单的JSON配置文件来描述角色层次。这段代码我曾在某个项目的审计模块里用过：
{
"roles": [
{
"roleId": "admin",
"displayName": "系统管理员",
"parentRoles": [],
"permissions": ["user.*", "audit.read", "config.write"]
},
{
"roleId": "operator",
"displayName": "操作员",
"parentRoles": ["admin"],
"permissions": ["order.*"],
"inheritanceMode": "selective",
"inheritableFromParent": ["order.read", "order.create"]
},
{
"roleId": "auditor",
"displayName": "审计员",
"parentRoles": ["admin"],
"permissions": ["audit.*"],
"inheritanceMode": "all",
"inheritSensitive": false
}
]
}
注意看inheritanceMode字段。操作员用了selective，只从管理员那里继承了订单相关的读和创建权限，没有继承config.write这种敏感权限。审计员用了all，但我额外加了个inheritSensitive: false，防止管理员权限泄露。
小技巧：如果权限值需要“叠加”而不是“覆盖”，在代码里用位运算或集合合并。我习惯用permissions = inheritPermissions ∪ ownPermissions，这样子角色可以拥有比父角色更多的权限，但不会丢失父角色的授权。
角色层次与权限传递的流程
下面这张图是我从一次故障复盘后画的。它展示了从根角色到叶子角色的权限传递路径，以及跨层阻断的位置：
看到上面的虚线箭头了吗？从“审计员管理员”到“审计操作员”用的是选择性继承——只传递读取审计日志的权限，不传递删除权限。还有底部的“隔层阻断”线，根管理员没法直接继承“数据录入员”和“报表查看员”的权限，必须经过中间层。
防坑指南：权限循环与爆炸
我曾经在一个老系统里发现角色继承形成了循环——A继承B，B继承C，C又继承A。结果权限解析器直接死循环了。所以每次设计角色层次，我一定会做两件事：
- 用拓扑排序检查角色图是否有环。
- 限制继承深度不超过3层，防止权限爆炸。
警告：不要将“组织架构”直接映射为“角色继承结构”。一个部门经理可能在组织上属于总裁，但权限上不一定需要继承总裁的全部权限。我曾经见过把CEO权限传给普通经理的案例——后果是经理能查看所有员工的薪资格子。正确的做法：组织架构仅用于汇报线，角色层次专门用于权限传递，两者独立设计。
审计检查清单
最后，我每次审计角色层次时都会对照这张清单：
- 是否所有角色都有明确的parentRoles字段？空数组算合法吗？
- 继承模式是全局配置还是角色级配置？我建议角色级更灵活。
- 是否有跨层继承的显式阻断机制？比如用“inheritanceDepth”限制。
- 权限冲突时，是“子覆盖父”还是“父覆盖子”？我选前者，更安全。
- 有没有审计日志记录每次继承关系的变更？没有就补上。
做好这几步，角色层次就不会成为权限泄露的突破口。你要是按我说的去设计，至少能少踩一半的坑。