WP角色继承混乱的根源在于缺乏明确层级定义和业务语义约束；需通过元数据+策略层重建显式DAG继承关系，统一权限标识，并严守管理关系真实性和权限叠加不可逆向覆盖两大铁律。

WP角色继承逻辑混乱，核心问题不在“有没有继承”，而在于继承关系缺乏明确层级定义和业务语义约束。Cl4权限层级（通常指RBAC3模型中的角色继承结构）需要从组织逻辑、权限粒度、变更成本三个维度重新对齐，而不是简单套用“上级包含下级权限”的直觉。

先理清Cl4的本质：不是四层，而是“可继承的层级化角色”

Cl4常被误认为是“用户→角色→子角色→权限”四层链路，实际它指的是RBAC模型中支持角色继承（Role Hierarchy）的完整形态。关键特征是：

• 角色之间存在显式父子关系（如“区域总监” → “大区经理” → “销售主管”）
• 父角色自动获得子角色全部权限，并可叠加额外权限（非覆盖，是并集）
• 继承路径必须为有向无环图（DAG），禁止循环依赖（如A→B→A）
• 权限判断时，系统需递归向上收集所有祖先角色的权限集合

为什么WP里继承会“乱”？常见三类断点

WP（WordPress）原生角色系统仅提供5个固定角色（Subscriber到Administrator），不支持自定义继承链。一旦插件或主题自行扩展角色并手动设置继承，极易出现：

• 隐式继承冲突：两个插件各自定义“Editor+”角色，都声称继承Editor，但叠加的权限互相覆盖或遗漏
• 组织脱钩：角色名含“华东”“2024Q3”等时效/地域标签，但未与WP用户所属的term或user meta绑定，导致继承失效
• 权限回溯断裂：某角色继承了A和B，但A被删除后，系统未触发权限重算，残留无效权限引用

重构Cl4层级的实操步骤

不推翻WP角色表结构，而是通过元数据+策略层重建继承逻辑：

• 用wp_usermeta存储用户所属的“组织节点ID”（如dept_id=107），替代硬编码角色名
• 新建wp_role_hierarchy表，字段为parent_role、child_role、active，显式声明继承关系
• 权限验证时，不再只查$user->roles，而是：
  ① 获取用户当前角色列表
  ② 根据wp_role_hierarchy向上递归获取所有祖先角色
  ③ 合并各角色在wp_options中配置的权限数组（如role_permissions_editor_v2）
• 所有权限标识统一为resource:action格式（如post:publish、usermeta:edit_others），避免中文描述或插件私有命名

避免越改越乱的两个铁律

Cl4重构不是给角色加更多层级，而是让层级真正承载业务含义：

• 继承必须对应真实管理关系：如果“内容审核员”不实际汇报给“主编”，就不要设继承；宁可多建一个中间角色，也不要伪造汇报线
• 权限叠加不可逆向覆盖：子角色定义post:edit_others，父角色不能通过继承关系取消该权限——要限制，就该用ABAC策略（如“仅限编辑自己部门发布的文章”）或数据范围隔离，而非在继承层做减法