2、权限继承基础概念：什么是权限继承？继承的方向与粒度

权限继承，说白了就是「上级有什么，下级自动有什么」。这个概念听起来简单，但我在好几个项目里都见过因为理解偏差导致的权限漏洞。今天咱们就把这个基础打扎实。

2.1 什么是权限继承？

权限继承是一种授权机制——子节点自动获得父节点的权限，不需要重复授权。你想想看，如果每个用户、每个资源都要单独配一遍权限，那系统根本没法维护。

举个例子：公司里部门经理有「查看部门报表」的权限，那么该部门下的所有员工自动继承这个权限。员工不需要再单独申请「查看部门报表」——这就是继承。

嗯，这里要注意：继承不是复制。父节点改了权限，子节点自动跟着变。我见过有人把继承理解成「一次性复制」，结果父节点权限收回后，子节点还留着权限，出了安全事故。

2.2 继承的方向：向上 vs 向下

继承方向是权限模型里最容易搞混的地方。我习惯用「树」来理解——有根、有枝、有叶。

2.2.1 向下继承（Top-Down）

这是最常见的继承方向。权限从根节点流向叶子节点。

• 典型场景：组织架构。公司 → 部门 → 小组 → 员工
• 规则：上级权限自动传递给下级
• 特点：权限只能增加，不能减少

我在项目中遇到过一个问题：某部门经理的权限被收回了「删除文档」权限，但该部门下的员工因为继承关系，还保留着这个权限。这就是向下继承的「单向性」——父节点减少权限，子节点不受影响？不对，实际上父节点减少权限后，子节点应该也失去继承来的权限。那次是代码实现有bug，查了两天才找到。

2.2.2 向上继承（Bottom-Up）

这个方向比较少见，但某些场景下很有用。子节点的权限可以向上传递给父节点。

• 典型场景：资源聚合。比如「项目A」包含「任务1」「任务2」，任务有「编辑」权限，项目自动获得「查看」权限
• 规则：子节点权限汇总到父节点
• 特点：常用于资源层级，而非组织层级

你想想看，向上继承其实更像「汇总」而不是「继承」。我建议在设计时把这两种方向分开命名，避免混淆。

维度	向下继承	向上继承
方向	父 → 子	子 → 父
常见场景	组织架构、角色树	资源聚合、文档目录
权限变化	子节点只能增加	父节点汇总子节点权限
实现复杂度	低	中

2.3 继承的粒度：角色、用户、资源

继承的粒度决定了「谁继承谁的权限」。我一般把粒度分成三层：角色级、用户级、资源级。

2.3.1 角色级继承

角色之间可以形成继承关系。比如「管理员」继承「编辑员」的权限，「编辑员」继承「访客」的权限。

// 角色继承示例（伪代码）
Role admin extends editor {
  permissions: ["delete_user", "system_config"]
}
Role editor extends visitor {
  permissions: ["edit_document", "approve"]
}
Role visitor {
  permissions: ["read_document"]
}

// admin 实际权限 = visitor + editor + admin
// = ["read_document", "edit_document", "approve", "delete_user", "system_config"]

这种粒度适合权限层级分明的系统。我曾经在一个SaaS项目中用角色继承来管理不同套餐的功能权限——基础版、专业版、企业版，每个版本继承上一个版本的权限，再加自己的专属功能。

2.3.2 用户级继承

用户通过所属的组织单元继承权限。比如用户A属于「研发部」，那么他自动继承「研发部」的所有权限。

• 继承路径：用户 → 部门 → 上级部门 → ... → 根组织
• 常见问题：用户同时属于多个部门时，权限如何合并？
• 我的建议：取并集，不要取交集。用户属于A部门和B部门，就拥有A+B的所有权限

用户级继承是最自然的继承方式，但也最容易出问题。我记得有一次，一个用户被移出了部门，但系统没有及时清除继承来的权限，导致他还能访问部门数据。后来我们加了一个定时任务做权限同步。

2.3.3 资源级继承

资源本身也有层级关系，权限沿着资源树传递。比如文件夹A包含文件B，用户对文件夹A有「编辑」权限，那么对文件B也自动有「编辑」权限。

// 资源树示例
/项目文档
  /设计稿
    /UI设计图_v1.png
    /UI设计图_v2.png
  /需求文档
    /PRD_v1.docx
    /PRD_v2.docx

// 用户对「设计稿」有「编辑」权限
// 自动继承到「UI设计图_v1.png」和「UI设计图_v2.png」

资源级继承在文件系统、文档管理系统中非常常见。但要注意一个坑：资源移动时，权限继承关系会断裂。我曾经遇到一个案例，用户把文件从「公开文件夹」移到「机密文件夹」，结果权限没跟着变，机密文件变成了公开可访问。

2.4 三种粒度的对比

粒度	继承主体	典型场景	维护成本	灵活性
角色级	角色 → 角色	权限模板、套餐管理	低	中
用户级	组织 → 用户	公司组织架构	中	高
资源级	父资源 → 子资源	文件系统、文档目录	高	低

2.5 权限继承的核心逻辑图

下面这张图展示了权限继承的完整链路。我习惯用这种图来跟团队对齐设计思路。

2.6 设计时的三个关键问题

每次设计权限继承模型，我都会问团队三个问题。你也可以拿来自检：

1. 继承方向明确了吗？是向下还是向上？还是双向？双向继承非常复杂，我建议除非必要，否则只用单向。
2. 继承粒度选对了吗？角色级适合通用权限，用户级适合组织管理，资源级适合数据隔离。不要混用。
3. 继承冲突怎么处理？当多个继承路径给同一个节点带来不同权限时，系统必须有一个确定的合并规则。我习惯用「最大权限优先」——取所有继承来源的并集。