Voter权限被拒主因是supports()过早失败、voteOnAttribute()校验缺失或服务未注册。supports()须轻量精准，仅匹配类型与操作名；voteOnAttribute()需覆盖所有拒绝路径并显式返回；服务须手动注册标签且access_control触发条件要正确。
权限被拒不是配置写错了，而是 Voter 没生效或逻辑卡在了关键环节。核心问题往往出在三个地方：supports() 判断过早失败、voteOnAttribute() 缺少必要校验、服务注册或触发条件不满足。
supports() 必须轻量且精准
这个方法是 Voter 的“门禁”，只负责快速匹配类型和操作名，不做任何业务判断或数据库查询。
- 检查 $attribute 是否为预期值（如 'EDIT'、'DELETE'），用严格相等 ===，避免字符串隐式转换出错
- 确认 $subject 是目标实体实例，用 instanceof Post，别用 get_class() 或字符串比对
- 绝对不要在这里调用 $post->isPublished()、$user->hasPermission() 等方法——这些必须挪到 voteOnAttribute() 中
voteOnAttribute() 要覆盖所有拒绝路径
这是真正做决策的地方，逻辑要完整，尤其注意“未认证”和“无权访问”两种拒绝场景不能混同。
- 开头先判 token 和 user：if (!$token || !$token->getUser() instanceof UserInterface) { return self::ACCESS_DENIED; }
- 取出 subject 后，立刻检查是否为空或类型不符，避免后续空指针
- 按 attribute 分支处理：作者校验、角色兜底、状态拦截（如已发布不可删除）都放在这里
- 每个分支末尾必须显式返回 ACCESS_GRANTED 或 ACCESS_DENIED；漏掉 return 就等于 abstain，可能被其他 Voter 覆盖
服务注册与触发条件常被忽略
Voter 写得再好，没进投票链也白搭。Symfony 不会自动发现 Voter，必须手动注册并满足 access_control 的触发门槛。
- 在 config/services.yaml 中明确打标签：tags: ['security.voter']
- access_control 规则里 roles 值不能是 ROLE_USER 这类纯角色——它会直接放行，跳过 Voter 链；必须用 IS_AUTHENTICATED_REMEMBERED 或更高
- @IsGranted("EDIT", subject="post") 中的 subject="post" 要和控制器方法参数名完全一致，且参数要有正确类型提示：public function edit(Post $post)
Spring Security 的 Voter 实现要点
Spring 的 AccessDecisionVoter 机制逻辑类似，但集成方式不同：
- 实现 AccessDecisionVoter 接口，重写 supports() 和 vote() 方法
- vote() 中遍历用户权限 authorities，逐个比对 ConfigAttribute.getAttribute()，注意权限前缀（如 ROLE_）是否匹配
- 需将自定义 Voter 注入到 AccessDecisionManager（如 AffirmativeBased）的 voters 列表中
- 若要求“必须拥有全部权限才放行”，不能依赖默认 RoleVoter，得自定义逻辑并在 vote() 中统计通过数
