权限继承失效多因角色前缀不符：Spring Security要求hasRole("ADMIN")实际匹配"ROLE_ADMIN"，若数据库存"admin"或未加前缀则无法识别；正确做法是统一构造SimpleGrantedAuthority("ROLE_"+role)并验证authentication.getAuthorities()全为ROLE_XXX格式。

权限继承失效，十有八九卡在 Role Prefix（角色前缀）上。Spring Security 默认要求所有角色必须以 ROLE_ 开头，否则 hasRole("ADMIN") 这类表达式根本不会匹配——不是逻辑写错了，是连识别都没被识别。

ROLE_ 前缀是硬性约定，不是可选项

Spring Security 内部的 DefaultMethodSecurityExpressionHandler 和 WebSecurityExpressionRoot 在解析 hasRole() 时，会自动给传入参数加上 "ROLE_" 前缀再比对。也就是说：

• hasRole("ADMIN") 实际查的是 "ROLE_ADMIN"
• 如果你数据库里存的角色是 "admin" 或 "ADMIN"（没加前缀），它永远找不到匹配项
• 哪怕你配置了完整的 RoleHierarchy，只要 GrantedAuthority 列表里没有 "ROLE_ADMIN" 这个字符串，继承关系就无从触发

常见前缀错误场景

这些情况看似细微，但都会导致权限继承“静默失败”：

• 从数据库查出角色名是 "admin"，直接 new SimpleGrantedAuthority("admin") → 缺少 ROLE_
• 角色名写成 "Role_Admin" 或 "role_admin" → 大小写或下划线位置不对，不等于标准 "ROLE_ADMIN"
• 用了自定义 UserDetailsService，但忘了在封装 SimpleGrantedAuthority 时统一拼接前缀
• 前端传来的角色名经 JWT 解析后未标准化，后端直接塞进 GrantedAuthority

正确做法：统一前置补全

最稳妥的方式，是在构建用户权限时主动补全前缀，而不是依赖框架“猜”：

• 从 DB 或 JWT 拿到原始角色标识（如 "ADMIN"、"USER"）
• 显式构造：new SimpleGrantedAuthority("ROLE_" + roleCode.toUpperCase())
• 确保所有角色都走同一套封装逻辑，包括直接角色和通过 RoleHierarchy 继承来的角色
• 验证方式：打印 authentication.getAuthorities()，确认列表中全是 ROLE_XXX 格式

不想用 ROLE_ 前缀？可以，但要全局改

如果业务强要求去掉前缀（比如兼容旧系统角色命名），必须显式覆盖默认前缀行为：

• 方式一：注入 GrantedAuthorityDefaults Bean，传空字符串
• 方式二：自定义 DefaultWebSecurityExpressionHandler，重写 createSecurityExpressionRoot，调用 root.setDefaultRolePrefix("")
• ⚠️ 注意：两种方式都要作用于整个安全上下文，不能只改某一个配置类