<p>必须使用 Voter 机制实现细粒度权限控制，禁用 ROLE_* 粗粒度检查；创建继承 AbstractVoter 的 PostVoter 类，supports() 仅做轻量匹配，voteOnAttribute() 处理业务逻辑；需注册为 security.voter 服务，且避免 access_control 拦截 Voter 执行。</p>
要在 Symfony 6.4 中实现细粒度的权限控制，必须绕过角色（ROLE_*）的粗粒度限制，直接使用 Voter 机制对具体对象和操作进行动态判断——比如“用户能否编辑这篇草稿”“管理员能否删除已发布的评论”，而不是简单检查是否拥有 ROLE_EDITOR。
创建 Voter 类
在 src/Security/Voter/ 目录下新建 PostVoter.php 文件，继承 AbstractVoter（推荐，自带缓存支持）：
这一步不能用 VoterInterface 手动实现——它不带缓存逻辑，每次调用都执行完整判断，性能差且易被绕过。
类开头必须声明命名空间和 use 语句，尤其注意 use App\Entity\Post; 和 use Symfony\Component\Security\Core\Authentication\Token\TokenInterface; 缺一不可，否则 instanceof Post 判断永远返回 false。
在 supports() 方法中只做轻量匹配：检查 $attribute 是否为 'EDIT' 或 'DELETE'，再确认 $subject 是 Post 实例。这里【绝不能查数据库、不能调服务、不能判状态（如 isPublished()）】——所有业务逻辑必须留在 voteOnAttribute() 里。
编写 voteOnAttribute() 判断逻辑
先确保当前用户已认证：if (!$token->getUser() instanceof UserInterface) { return self::ACCESS_DENIED; }
取出 subject：$post = $subject;
获取当前用户：$user = $token->getUser();
根据 attribute 分支判断：
若 $attribute === 'EDIT'，则检查 $user->getId() === $post->getAuthor()->getId() 或 $user->hasRole('ROLE_ADMIN')；
若 $attribute === 'DELETE'，则额外加一道状态校验：if ($post->isPublished()) { return self::ACCESS_DENIED; }——这才是业务规则该出现的位置。
注册 Voter 为服务并打标签
打开 config/services.yaml，在 services: 下添加：
App\Security\Voter\PostVoter:
tags: ['security.voter']
这一步漏掉就等于没写 Voter——Symfony 根本不会把它加入 Voter 链，@IsGranted("EDIT", subject="post") 会静默跳过，直接返回 deny。
不要手动调用 isGranted() 测试时传错 subject 类型：控制器方法参数名必须与注解中 subject="post" 完全一致，且类型提示为 Post $post，否则 $subject 是 null，supports() 直接返回 false。
在控制器或模板中触发 Voter
方法一：用注解，在控制器方法上加 @IsGranted("EDIT", subject="post")，同时确保方法签名含 Post $post 参数。
方法二：在 Twig 模板中用 {% if is_granted('DELETE', post) %} 控制按钮显示。
方法三：在服务中手动调用：$this->authorizationChecker->isGranted('EDIT', $post)。
注意：如果路由配置了 access_control 规则且匹配成功（例如 roles: ROLE_EDITOR），Symfony 会跳过整个 Voter 链——想让 Voter 生效，access_control 的 roles 至少得设为 IS_AUTHENTICATED_REMEMBERED 或更低。
