权限继承循环是设计隐患而非配置错误，会导致授权系统无法判定角色关系而陷入死循环，引发权限校验失效、服务启动失败或请求卡死。

权限继承循环不是配置错误，而是设计隐患——它会让授权系统陷入无法判定角色关系的死循环，轻则权限校验失效，重则服务启动失败或请求卡死。

什么是权限继承循环

当角色层级中出现闭环定义时，就构成继承循环。例如：

• ROLE_A → ROLE_B → ROLE_C → ROLE_A
• ROLE_ADMIN → ROLE_MANAGER → ROLE_STAFF → ROLE_ADMIN
• 或间接循环：ROLE_SUPER → [ROLE_ADMIN, ROLE_AUDITOR]，而 ROLE_AUDITOR → ROLE_SUPER

这种结构让角色可达性（reachable roles）计算无法收敛，系统无法确定一个角色最终能“到达”哪些其他角色。

Hierarchy Check 检查法（主动验证）

不能依赖运行时报错——多数权限框架（如 Symfony、Spring Security）在检测到循环时选择静默忽略、跳过整个 hierarchy 配置，或在启动阶段直接抛出异常。因此必须主动检查：

• 在 Symfony 中：运行 php bin/console debug:security --hierarchy，若输出为空或提示 “No role hierarchy defined”，说明配置被跳过，需排查循环或格式问题
• 在 Spring Security 中：启动时启用 logging.level.org.springframework.security.access.hierarchicalroles=DEBUG，观察日志是否出现 Detected cyclic role hierarchy
• 手动图谱分析：把所有 role_hierarchy 或 ROLE_X > ROLE_Y 关系画成有向图，用拓扑排序或 DFS 检测环（推荐工具：Graphviz + dot 文件可视化）

避免循环的实操原则

层级应是单向、无环、分层清晰的树状结构，而非网状：

• 只允许“向上继承”：子角色 → 父角色（如 ROLE_EDITOR → ROLE_USER），禁止反向或跨级回指
• 避免多路径通向同一角色：例如 ROLE_ADMIN → ROLE_USER 和 ROLE_MODERATOR → ROLE_USER 是安全的；但若再加 ROLE_ADMIN → ROLE_MODERATOR，就可能隐含循环风险（尤其当 ROLE_MODERATOR 又反向依赖 ROLE_ADMIN 时）
• 数据库动态角色场景下，禁止在角色关系表中插入会导致环的记录——应在写入前执行环检测 SQL（如用递归 CTE 查询所有祖先角色并比对）

发现循环后怎么修复

不要简单删掉某条规则——先厘清业务语义：

• 确认是否真需要该继承关系？很多所谓“双向权限需求”，实际可通过合并角色（如新建 ROLE_ADMIN_AND_AUDITOR）或改用权限（Permission）而非角色（Role）建模来解决
• 用“角色组合”替代“继承”：access_control 中显式列出多个角色（roles: [ROLE_ADMIN, ROLE_AUDITOR]），不依赖 hierarchy 展开
• 引入中间抽象层：例如定义 ROLE_OPERATIONAL 作为 ROLE_ADMIN 和 ROLE_AUDITOR 的共同父角色，再让两者都继承它，消除直接互指