role_hierarchy必须配置在security.yaml顶层，与firewalls、access_control同级；若位置错误或角色名不规范（如大小写/前缀错误），继承将静默失效，isgranted()仍正常但getroles()不展开父角色。
role_hierarchy 配置必须写在 security.yaml 的顶层
不是放在 firewalls 或 access_control 里，而是和它们同级。漏掉这层结构，Symfony 就完全忽略继承定义。
常见错误现象：isGranted('ROLE_ADMIN') 返回 true，但访问本该继承的 ROLE_USER 资源时被拒绝；dump($this->getUser()->getRoles()) 显示只有 ['ROLE_ADMIN']，没自动补上父角色。
- 正确位置示例：
security:
role_hierarchy:
ROLE_ADMIN: ROLE_USER
ROLE_SUPER_ADMIN: [ROLE_ADMIN, ROLE_ALLOWED_TO_SWITCH]
firewalls:
# ...
access_control:
# ...
注意：值可以是单个字符串（如 ROLE_USER），也可以是数组（如 [ROLE_ADMIN, ROLE_ALLOWED_TO_SWITCH]），但键必须是合法角色名（以 ROLE_ 开头）。
角色名大小写敏感且必须带 ROLE_ 前缀
哪怕只差一个下划线或大小写，role_hierarchy 就不会生效。Symfony 不做容错转换，也不会报错，只是静默跳过。
使用场景：从数据库加载用户时，getRoles() 返回的数组里如果混入了 'role_user' 或 'RoleUser'，整个继承链就断了。
- ✅ 合法角色名：
ROLE_USER、ROLE_EDITOR、ROLE_API_CLIENT - ❌ 非法角色名：
role_user、UserRole、user、ROLE-USER - 检查方法：在控制器里加
dump($this->getUser()->getRoles())，确认输出全是大写+下划线格式
继承不自动“展开”到 getRoles() 返回值里
role_hierarchy 只影响授权决策（isGranted()、access_control），不会修改用户对象本身的 getRoles() 返回结果。这是最容易误解的一点。
性能影响：不展开反而更轻量——避免每次查用户都做递归合并；但开发调试时容易误以为配置失败。
- 例如：用户只拥有
ROLE_ADMIN，getRoles()仍返回['ROLE_ADMIN']，但isGranted('ROLE_USER')会返回true - 若需显式获取所有可继承角色，得手动调用
$this->security->getRoleHierarchy()->getReachableRoles($user->getRoles()) - access_control 中的
roles: [ROLE_ADMIN]会隐式包含其继承链，无需写成[ROLE_ADMIN, ROLE_USER]
多级继承要避免循环引用
Symfony 不校验循环，一旦配置成 ROLE_A: ROLE_B 且 ROLE_B: ROLE_A，运行时可能触发无限递归或静默失败（取决于 PHP 版本和 Symfony 小版本）。
兼容性影响：Symfony 5.4+ 对角色解析做了更严格的栈深度限制，循环会直接抛出 LogicException；旧版本可能卡死或返回意外结果。
- 安全写法：用树状结构，单向向下继承，例如
ROLE_USER → ROLE_EDITOR → ROLE_ADMIN → ROLE_SUPER_ADMIN - 调试技巧：在测试中调用
$this->security->getRoleHierarchy()->getReachableRoles(['ROLE_SUPER_ADMIN'])看是否返回预期全集 - 特别注意第三方 Bundle（如 Sylius）自带的角色定义，别在自定义配置里重复覆盖或反向继承
实际项目里最常被忽略的是继承与 getRoles() 的分离逻辑——它不改数据，只改判断。这点不厘清，排查权限问题就会一直绕圈子。
