📚 课程目录第3章角色层级设计

3、角色层级设计：角色树的构建、父角色与子角色的关系、角色继承的传递性

权限模型里，角色不是一堆散落的标签。它们之间应该有清晰的层级关系。说白了，就是一棵树。

我刚开始做权限系统时，把角色全平铺在数据库里。每个用户单独配角色，每个角色单独配权限。结果呢？维护成本直线上升。后来我意识到，现实世界中的组织架构本身就是树形的——总经理管总监，总监管经理，经理管员工。权限模型为什么不这么做？

3.1 角色树：从根到叶的权限脉络

角色树，就是把所有角色按照从通用到具体、从高权限到低权限的层次组织起来。根节点通常是「超级管理员」或「系统管理员」，叶子节点是「普通员工」或「访客」。

构建角色树时，我习惯遵循几个原则：

单一父节点：每个子角色只有一个直接父角色。这能避免权限冲突和循环依赖。
层级深度可控：树的高度一般不超过5层。太深了，权限传递会变得难以追踪。
职责内聚：同一分支下的角色，职责范围应该相近。比如「销售总监」和「销售经理」放在销售分支下。

举个例子，一个典型的企业权限角色树：

系统管理员
├── 运营总监
│   ├── 运营经理
│   │   ├── 运营专员
│   │   └── 客服专员
│   └── 数据分析师
├── 销售总监
│   ├── 销售经理
│   │   ├── 销售代表
│   │   └── 渠道专员
│   └── 市场经理
│       └── 市场专员
└── 财务总监
    ├── 财务经理
    │   ├── 会计
    │   └── 出纳
    └── 审计专员

你看，每个节点都只有一个父节点。运营经理只能继承运营总监的权限，不会混入销售总监的权限。这就是单一继承的好处。

核心要点：角色树的结构决定了权限继承的路径。树越清晰，权限管理越简单。

3.2 父角色与子角色：继承与扩展

父角色和子角色的关系，说白了就是「基础 + 扩展」。子角色自动拥有父角色的所有权限，然后可以增加自己的专属权限，也可以限制某些权限。

我遇到过一种情况：子角色需要继承父角色的大部分权限，但有一两个权限必须去掉。比如「出纳」继承「财务经理」的权限，但「审批付款」这个权限不能给。怎么办？

这里有几种处理方式：

策略	说明	适用场景
正向继承	子角色自动获得父角色所有权限，只能增加不能减少	权限要求严格的系统，如金融、医疗
负向覆盖	子角色可以显式拒绝继承某个权限	需要灵活调整权限的企业应用
白名单模式	子角色只继承父角色中明确标记为「可继承」的权限	多租户系统，租户间权限隔离

我个人比较推荐「正向继承 + 负向覆盖」的组合。子角色默认继承所有父权限，但可以通过一个「拒绝列表」来排除不需要的权限。这样既保持了继承的简洁性，又提供了灵活性。

实践建议：在设计数据库时，为角色表增加一个 denied_permissions 字段，存储子角色拒绝继承的权限ID列表。查询时，先取父角色的权限，再减去拒绝列表中的权限。

3.3 角色继承的传递性：链条上的权限流动

角色继承的传递性，指的是权限沿着角色树向上传递。子角色拥有父角色的权限，父角色拥有祖父角色的权限，以此类推。

举个例子：

「系统管理员」拥有「查看系统日志」权限
「运营总监」继承「系统管理员」的权限，所以也拥有「查看系统日志」
「运营经理」继承「运营总监」的权限，同样拥有「查看系统日志」
「运营专员」继承「运营经理」的权限，最终也拥有「查看系统日志」

这就是传递性。权限从根节点一直流到叶子节点。

我曾经踩过一个坑：角色树有6层深，某个叶子角色的权限莫名其妙多了出来。查了半天，发现是中间某个父角色被错误地赋予了不该有的权限，然后一路传递下来。从那以后，我要求所有角色树深度不超过4层，并且每次修改父角色权限时，必须评估对子角色的影响。

注意：传递性是一把双刃剑。它简化了权限分配，但也放大了错误的影响范围。修改高层角色的权限时，一定要谨慎。

实现传递性查询时，我推荐使用递归查询或预计算路径。比如在MySQL中，可以用递归CTE：

WITH RECURSIVE role_path AS (
  SELECT id, parent_id, name, 1 AS level
  FROM roles
  WHERE id = :target_role_id
  UNION ALL
  SELECT r.id, r.parent_id, r.name, rp.level + 1
  FROM roles r
  INNER JOIN role_path rp ON r.id = rp.parent_id
)
SELECT * FROM role_path ORDER BY level DESC;

这个查询会返回从目标角色到根节点的完整路径。然后你只需要收集路径上所有角色的权限，合并去重即可。

3.4 角色树的可视化：一张图看懂层级

说了这么多理论，不如一张图来得直观。下面是我用SVG绘制的一个角色树示例，展示了父角色、子角色以及权限的传递关系。

嗯，这张图把角色树的层级、父角色与子角色的关系、权限的传递路径都展示清楚了。你可以看到，权限从「系统管理员」一路流到「出纳」，中间经过「财务总监」和「财务经理」。每个子角色都站在父角色的肩膀上。

3.5 避坑指南：角色层级设计中的常见问题

最后，分享几个我在项目中踩过的坑：

循环继承：A继承B，B继承C，C又继承A。这会导致无限递归。我曾在测试环境遇到过，数据库直接爆了。解决方案：在代码中检测循环依赖，或者限制继承深度。
过度继承：把所有权限都放在根角色，子角色只做减法。结果根角色权限爆炸，改一个权限影响所有子角色。建议：权限尽量下沉到合适的层级，根角色只保留真正通用的权限。
忽略性能：每次查询权限都递归遍历整棵树。用户量一上来，数据库扛不住。我后来改用预计算路径+缓存，查询时间从秒级降到毫秒级。

小技巧：在角色表中增加一个 path 字段，存储从根到当前角色的路径ID列表（如 "1,3,5,7"）。查询时直接用 FIND_IN_SET 或 IN 操作，避免递归。

角色层级设计，说白了就是给权限系统搭骨架。骨架搭好了，后面的权限分配、权限验证、权限审计都会顺畅很多。别急着写代码，先画好你的角色树。