isgranted() 总是返回 false 的根本原因是运行时安全上下文缺失：用户未认证、防火墙未覆盖请求路径，或角色命名/实现不规范（如 getroles() 未返回非空字符串数组）。
Symfony 6.0 的安全组件默认启用鉴权（authorization）逻辑，但isGranted()调用失败或始终返回 false，通常不是权限配置遗漏，而是防火墙未激活、用户未认证，或角色命名不匹配——这三个点踩中任意一个，isGranted('ROLE_ADMIN') 就会静默失效。
为什么 isGranted() 总是返回 false？
这不是函数本身的问题，而是运行时上下文缺失。Symfony 6.0 要求：用户必须已通过认证（即 $user 存在于 TokenStorage 中），且该用户实例必须实现 UserInterface 并正确返回 getRoles() 数组（注意：返回值必须是字符串数组，不能是空数组或 null）。
-
security.yaml中的firewall必须覆盖当前请求路径（例如pattern: ^/），否则整个安全上下文不启动 - 控制器里直接调用
$this->isGranted('ROLE_ADMIN')前，确认当前请求已进入防火墙范围（可通过dump($this->getUser())验证是否为App\Entity\User实例） - 自定义
User类中getRoles()方法若依赖数据库字段（如$this->roles），需确保该属性被序列化（加@ORM\Column(type: "json")或手动实现serialize()）
access_control 不生效？检查匹配顺序和路径写法
Symfony 6.0 的 access_control 是按顺序匹配的，第一条匹配即终止，后续规则不再检查。常见错误是把宽泛路径（如 ^/admin）放在窄路径（如 ^/admin/users）之后。
- 路径必须以
^开头，且是正则前缀匹配，不是 glob 模式：path: ^/api/匹配/api/posts，但path: /api不匹配任何请求 - 角色名区分大小写，
ROLE_ADMIN和role_admin是两个不同角色 -
roles字段接受数组或逗号分隔字符串，但推荐统一用数组：roles: ['ROLE_ADMIN', 'ROLE_EDITOR'] - 若使用表达式（
expression），需开启symfony/expression-language，且表达式中引用用户属性必须用user变量，例如"user.isVerified()"
自定义 Voter 时，supports() 返回 true 但 voteOnAttribute() 没执行
这是最隐蔽的坑：Voter 被注册了，但没被调用，往往因为 supports() 判断逻辑有误。Symfony 6.0 对 attribute 和 subject 的类型校验更严格。
-
supports(string $attribute, $subject)中，$attribute是你传给isGranted('EDIT_POST', $post)的第一个参数，必须完全一致（包括大小写） -
$subject类型必须匹配——如果传入的是 Doctrine 实体，Voter 中if (!$subject instanceof Post) { return false; }是必须的，否则直接跳过 - Voter 类必须标记为
#[AsVoter]（Symfony 6.2+）或在services.yaml中显式声明tags: [{ name: 'security.voter' }] - 调试技巧：在
supports()开头加throw new \Exception("voter called");，看是否抛出异常；没抛，说明根本没轮到这个 Voter
CSRF 保护导致表单登录失败，但错误信息不明确
Symfony 6.0 默认启用 CSRF 保护，form_login 会验证 token，但错误常表现为“Bad credentials”，而非“Invalid CSRF token”。真正原因可能是模板里漏了 {{ csrf_token('authenticate') }} 或表单 action 地址不对。
- 登录表单必须包含隐藏字段：
<input type="hidden" name="_csrf_token" value="{{ csrf_token('authenticate') }}"> -
form_login的login_path必须指向一个允许匿名访问的路由（即该路径不在access_control的保护范围内） - 若使用 API 登录（JSON），禁用 CSRF 是合理的，但需显式设置：
json_login: { csrf_parameter: false }，否则请求会被拦截 - CSRF token 默认绑定到 session，若用户频繁切换域名或禁用 cookie，token 会失效——此时应检查
framework.session.cookie_samesite是否设为lax或strict
真正卡住人的地方，从来不是配置项本身，而是 Symfony 6.0 把“认证完成”和“鉴权可用”拆成了两个强依赖阶段：用户对象存在、角色可读、防火墙激活、路径匹配、Voter 注册——缺一不可。少查一步，isGranted() 就安静地返回 false，连日志都不打。
