Symfony RBAC角色判断需以ROLE_开头，access_control按顺序匹配，动态权限用带security.voter标签的自定义Voter，switch_user仅限dev环境启用。
直接用 isGranted() 判断角色是最简单有效的起点
Symfony 的 RBAC 不需要额外安装包，核心功能已内置。你只需在控制器、模板或服务里调用 isGranted('ROLE_ADMIN') 就能判断当前用户是否拥有该角色。注意：角色名必须以 ROLE_ 开头，否则 isGranted() 会静默失败——这是最常被忽略的命名规则。
常见错误现象：isGranted('admin') 返回 false，但用户明明在数据库里被赋了 admin 权限。原因就是没加前缀。
- 角色字符串必须全大写且带
ROLE_前缀，如ROLE_EDITOR - 多个角色用数组传入：
isGranted(['ROLE_ADMIN', 'ROLE_EDITOR'])表示“任一满足” - 在 Twig 模板中用
{% if is_granted('ROLE_ADMIN') %}，语法一致
用 access_control 在路由层拦截未授权访问
这是最常用也最容易配错的环节。配置写在 config/packages/security.yaml 的 access_control 下，顺序很重要——匹配是自上而下执行的，一旦命中就停止检查。
典型陷阱：把宽松规则（如 path: ^/）放在前面，导致后面更具体的规则（如 path: ^/admin）永远不生效。
- 路径必须用正则语法，
^/admin匹配/admin和/admin/users，但/admin/不匹配/admin - 角色检查用
roles: [ROLE_ADMIN]，不是字符串'ROLE_ADMIN' - 允许匿名访问要显式写
roles: IS_AUTHENTICATED_ANONYMOUSLY，不能留空
自定义 Voter 是处理动态权限（如“编辑自己文章”）的唯一可靠方式
当权限逻辑依赖具体对象（比如用户 ID、文章作者、部门归属），纯角色控制就失效了。Voter 是 Symfony 提供的扩展点，它让你在运行时决定是否放行。
容易踩的坑：Voter 类没注册为服务，或没加 security.voter 标签，导致完全不被调用。
- 继承
AbstractVoter，重写supports()和voteOnAttribute() - 在
services.yaml中必须加上tags: [{ name: 'security.voter' }] - 在代码中触发：
$this->isGranted('EDIT', $article)，其中EDIT是自定义 attribute，$article是 subject 对象 - 不要在 Voter 里做耗时操作（如查库），先用缓存或预加载数据
switch_user 调试时很香，但上线前务必禁用
开发阶段用 switch_user 可以快速切换不同角色用户测试权限逻辑，命令是 /login?_switch_user=alice。但它默认开启时存在严重安全隐患：任意登录用户只要知道其他用户名就能冒充。
线上环境一旦漏掉关闭配置，等于主动开放越权入口。
- 只在
dev环境启用：switch_user: { firewall: main, provider: app_user_provider }放在security.yaml的dev配置块内 - 生产环境必须确保
switch_user完全不存在于配置中，而不是设为false - 如果用了 API Token 或 JWT，
switch_user不生效，别指望它能帮你测 token 场景
access_control 顺序错、或者 Voter 忘记打标签。动态权限逻辑越复杂，越要尽早拆出 Voter，别堆在控制器里硬编码判断。 
