角色继承与权限传播
角色层次这东西，说白了就是给权限做"结构化收纳"。你想想看，一个几百人的公司，要是每个角色都平铺着定义，那权限表早炸了。我最早接触RBAC时，也想过"搞这么复杂干嘛"，直到在一次客户现场，看到人家几千个角色摊在一张Excel里……嗯，从那以后我彻底服了。
这一章我们聊聊角色继承的核心逻辑。包括角色层次怎么设计、权限到底往哪个方向传、以及落地时最容易踩的坑。
1. 角色层次：不只是"谁大谁小"
角色层次（Role Hierarchy）在RBAC里是一个偏序关系。通俗点说，就是定义"哪个角色包含哪个角色"。我习惯把它看作一棵树——父节点在上，子节点在下。父节点天然拥有子节点的所有权限，但子节点不会反向拥有父节点的权限。
举个例子："部门主管"这个角色，自动包含"项目经理"的所有权限，但项目经理不能越级去行使主管的审批权。这就是层次结构带来的边界感。
2. 权限继承规则：向上还是向下？
这块是很多初学者容易绕晕的地方。我直接说结论——标准RBAC模型里，权限是向上继承的。也就是子角色的权限向父角色汇聚。
| 继承方向 | 含义 | 标准RBAC支持 | 典型场景 |
|---|---|---|---|
| 向上继承 | 父角色获得子角色的全部权限 | ✅ 核心特性 | 组织层级、管理链 |
| 向下继承 | 子角色获得父角色的部分/全部权限 | ❌ 非标准，需扩展 | 临时授权、委派 |
| 双向继承 | 父子角色互相继承权限 | ⚠️ 极少使用 | 极少场景，风险高 |
向上继承是RBAC的基石。你想想看，如果CEO还要一个个去勾选普通员工的权限，那系统就没法用了。我见过最夸张的一个项目，客户要求"管理员能看到所有子角色的数据"——这就是典型的向上继承需求，只不过他们当时不知道这个术语。
2.1 向上继承的传递性
权限沿着角色链一路向上传递。中间不会断，也不会打折。
- 如果"工程师"有"查看代码库"的权限
- "高级工程师"继承了工程师的权限
- "项目经理"继承了高级工程师的权限
- 那么项目经理也能查看代码库——即使他没被直接赋予这个权限
这就是传递性的威力。设计时一定要想清楚：某个权限给到最底层的角色后，会不会一路传到顶层？
2.2 向下继承：什么时候用？
向下继承不是标准RBAC的内容，但在实际项目中偶尔会遇到。我通常只在两种场景下使用它：
- 临时授权：上级把自己的一部分权限临时委派给下级，比如"经理外出期间，主管代行审批权"
- 默认基线：公司级的通用权限（如"遵守信息安全规范"）自动下发给所有角色
但注意，向下继承容易被滥用。我建议在系统设计时就把向下继承做成"白名单"机制——默认关闭，需要时显式开启。
3. 设计原则：五个一定要记住的点
这些年我总结了几条实用原则。不是什么教科书上的大道理，都是真金白银换来的经验。
| 原则 | 说明 | 违反后果 |
|---|---|---|
| ① 最小权限 | 每个角色只拥有完成工作所必需的最小权限集 | 权限泛滥，安全漏洞 |
| ② 层次扁平化 | 角色层次不超过5层，越深越难管理 | 继承链路过长，权限失控 |
| ③ 禁止循环继承 | 角色之间不能形成A→B→C→A的闭环 | 系统崩溃，无限递归 |
| ④ 职责分离 | 互斥角色不能处于同一条继承链上 | 利益冲突，违规操作 |
| ⑤ 继承显性化 | 每个角色的权限要能追溯来源：是直接赋予还是继承而来 | 排查困难，审计失败 |
第⑤条特别重要。我做过一个事后审计的项目，客户完全分不清某个权限是直接给的还是继承来的。最后我们不得不在权限表里加了一列 inherited_from，这才把账算清楚。
4. 实际案例：看看别人怎么做的
讲两个我参与过的真实项目，帮你把上面的规则串起来。
案例一：中型电商平台的权限体系
客户是一家200人规模的电商公司。他们的角色层次是这样设计的：
- L0 超级管理员：系统配置、数据全量访问
- L1 运营总监：继承L0部分权限 + 运营全模块
- L2 类目经理：继承L1的类目相关权限 + 商品上下架
- L3 运营专员：继承L2的指定类目权限 + 内容编辑
这里有个巧妙的设计：运营总监虽然继承了类目经理的权限，但不能修改专员的个人绩效数据——因为绩效数据被标记为"仅限直接上级查看"，而这个属性不随角色继承传递。
这种做法就是"继承 + 例外规则"的典型用法。我个人非常推荐这种组合方式，既保留了继承的便利性，又避免了权限一刀切。
案例二：医疗系统的严格管控
医疗项目对权限的要求极其严苛。我们当时设计了一套"双层过滤"机制：
- 第一层：角色继承（标准向上继承）
- 第二层：数据标签过滤（按科室、患者类型等属性二次校验）
举个例子："内科主任"继承了"内科医生"的所有权限，但当他尝试访问"外科"的患者数据时，第二层过滤会直接拦截。哪怕角色继承链上有"查看所有病历"的权限，也过不去。
这个设计后来成了我们团队的标配。你想想看，纯靠角色继承很难应对复杂的业务场景，搭配一层属性过滤就灵活多了。
5. 避坑指南：这些错我替你犯过了
最后聊几个常见陷阱。每一个都是我或者团队曾经摔过跟头的地方。
- 陷阱一：继承深度失控——角色链超过7层后，权限传播路径几乎不可追踪。我建议在系统里硬性限制最大深度，比如5层。
- 陷阱二：循环继承——A继承B，B继承C，C又继承A。这在某些配置灵活的系统中可能发生。一定要做环检测。
- 陷阱三：忽略互斥约束——两个互斥角色（如"采购"和"验收"）如果在同一条继承链上，就违反了职责分离原则。我曾经在ERP项目中因为这个被审计点名。
- 陷阱四：权限膨胀——底层角色每加一个权限，顶层角色就多一个权限。久而久之，超级管理员的权限集变得无比庞大。
好了，角色继承这块的核心内容基本都覆盖了。层次结构是RBAC的骨架，继承规则是血液，设计原则是免疫系统——三者配合好，权限体系才能健康运转。