角色层级仅影响角色继承检查，不参与Voter授权；Voter需正确实现supports()以触发voteOnAttribute()，且必须通过@IsGranted或denyAccessUnlessGranted显式调用才能生效。
角色层级（Role Hierarchy）管的是“谁有哪类权限”，投票器（Voter）管的是“对某个具体对象能不能做某件事”——两者不互斥，但分工明确；混用或错配，权限就失效。
role_hierarchy 配置写在哪、怎么生效
Symfony 的角色继承关系必须定义在 security.yaml 的 role_hierarchy 下，不能靠 PHP 类或注解动态生成。它只影响 $token->getRoles() 返回值，也就是角色检查（如 is_granted('ROLE_EDITOR')）时的展开逻辑。
- 层级只做单向展开：若配置
ROLE_ADMIN: [ROLE_EDITOR, ROLE_USER]，则拥有ROLE_ADMIN的用户自动拥有后两者，但反过来不成立 - 不支持循环引用：
ROLE_A: [ROLE_B]且ROLE_B: [ROLE_A]会抛出Symfony\Component\Security\Core\Exception\LogicException - 层级不参与 Voter 判断：Voter 的
supports()和voteOnAttribute()完全不感知 role_hierarchy，它只看当前 token 的实际角色和传入的$attribute/$subject - 常见错误是把业务规则塞进 hierarchy，比如
ROLE_AUTHOR: [ROLE_USER]+ROLE_EDITOR: [ROLE_AUTHOR]，以为能表达“作者可编辑自己的文章”——这做不到，得靠 Voter
Voter 的 supports() 方法为什么总返回 false
supports() 是 Voter 的“守门人”，返回 false 就直接跳过这个 Voter，后续 voteOnAttribute() 根本不会执行。90% 的失效源于这里。
- 拼写大小写不一致：
@IsGranted("edit", subject="post")传的是"edit"，但supports()里写了return $attribute === 'EDIT';→ 不匹配 -
$subject类型判断失败：没加use App\Entity\Post;，导致$subject instanceof Post永远为false - 传了 null subject：
@IsGranted("EDIT")没带subject=，或控制器参数名不匹配（如注解写subject="post"，但方法签名是Post $article）→$subject为null，instanceof必然失败 - 用了 Doctrine Proxy 类型：实体被代理后，
get_class($subject)可能返回类似App\Entity\Post\__CG__\App\Entity\Post，但instanceof Post仍为true；真正要防的是未 use 或命名空间错误
access_control 怎么触发 Voter
Voter 不是自动激活的——它只在 Symfony 明确进入“授权决策链”时才被调用。而 access_control 规则是否走到这一步，取决于你写的 roles: 值。
- 写
roles: ROLE_USER：角色匹配成功就放行，Voter 完全不触发 - 写
roles: IS_AUTHENTICATED_REMEMBERED或更高（如IS_AUTHENTICATED_FULLY,PUBLIC_ACCESS）：角色检查通过后，还会继续走 Voter 链 - 想强制走 Voter？别依赖 access_control，改用
@IsGranted("EDIT", subject="post")或手动调用$this->denyAccessUnlessGranted("EDIT", $post) - 多个 Voter 同时注册时，顺序无关紧要：Symfony 按全部 Voter 的
supports()结果汇总，只要有一个返回true，就会调用其voteOnAttribute()；全部返回false才算“无人支持”，最终投弃权票（ACCESS_ABSTAIN）
Voter 里查数据库或调服务的安全边界
supports() 必须轻量，但 voteOnAttribute() 是唯一允许做真实业务判断的地方。这里容易高估开销或低估缓存影响。
- 可以安全调用 Repository：
$this->postRepository->findAuthorId($subject->getId())，但别在循环里查多次 - 避免在 Voter 中调用外部 API 或写操作（如日志记录、状态变更），它可能被反复调用（模板中多次
is_granted()） - 注意 Doctrine 查询缓存：如果 Voter 里用了
$em->getRepository()->findOneBy(...)，默认不走查询缓存；要用$em->getUnitOfWork()->getEntityPersistanceState()或显式启用 DQL 缓存 - 性能敏感场景下，考虑提前把关键字段（如 author_id、status）加载进
$subject，避免每次投票都额外查库
真正难的不是写逻辑，而是让 Voter 在正确时机、以正确参数、被正确路径触发——漏掉任何一个环节，它就静默失效，连日志都不会打。
