access_control 按顺序匹配且 path 为正则（如 ^/api/），角色无默认继承需在 role_hierarchy 中定义，登录跳转失败多因 entry_point 或 session 配置错误，api 应单独配置 stateless 防火墙，修改后须清除缓存。
firewall 配置里 path 匹配不生效？检查 access_control 的顺序和路径语法
Symfony 的 access_control 是按顺序逐条匹配的，一旦某条规则匹配成功，后续规则就不再检查。很多人加了一条「允许 /api/」的规则，却放在了「拒绝所有未登录用户」的规则后面，结果根本进不去。
-
path值是正则表达式（从 Symfony 5.4+ 开始默认启用），不是 glob 或前缀匹配，^/api/才匹配以/api/开头的路径，/api/本身会匹配失败 - 如果用的是 Symfony 5.3 或更早版本，
path是前缀匹配，但建议统一升级并显式使用^/api/写法，避免混淆 - 注意 trailing slash：浏览器访问
/admin和配置path: "/admin/"不会匹配，得写成^/admin或^/admin/（取决于你是否接受带斜杠的变体）
ROLE_USER 能访问 /admin 吗？角色继承与 security.yaml 中的 role_hierarchy 设置
默认情况下，ROLE_USER 和 ROLE_ADMIN 是平级关系，不会自动继承。即使你在数据库里给用户分配了 ROLE_ADMIN，如果没在 security.yaml 里声明层级，access_control 中写 roles: [ROLE_ADMIN] 就只认这个角色，不认它的父角色（哪怕你心里觉得它“应该”有更高权限）。
- 必须在
security.yaml的role_hierarchy下明确定义继承关系，例如：ROLE_ADMIN: [ROLE_USER] - 继承只在授权检查（如
is_granted('ROLE_ADMIN')）时起作用，不影响access_control的角色列表校验逻辑 - 如果想让某个路径同时接受多个角色，直接写
roles: [ROLE_USER, ROLE_ADMIN]更直白，比依赖继承更可控
登录后跳转到 /admin 却被重定向回登录页？检查 firewall 的 entry_point 和 session 配置
这不是权限问题，而是认证流程卡在了入口点（entry point）。当用户没有权限访问目标路径时，Symfony 会尝试重定向到登录页；但如果防火墙没配好 entry_point，或 session 无法持久化，就会出现“刚登完就弹回登录页”的假象。
- 确认
main防火墙启用了form_login，且login_path和check_path路径没被其他access_control规则拦截（比如误加了roles: ROLE_USER到登录页） - 检查
session.handler_id是否为null（默认内存 session 在 CLI 或某些代理下会丢失），生产环境务必设为session.handler_id: 'session.handler.native_file'或 Redis 驱动 -
logout配置中的invalidate_session默认为true，登出时清空 session，这是预期行为；但若登出后立刻刷新页面又跳回登录页，大概率是 session 没真正写入或被拦截
API 接口要绕过 session 认证？用 stateless: true + guard 验证 token
Web 页面走 session，API 接口走 token，两者不能混用同一套 firewall 配置。强行把 /api/ 加进 main 防火墙并设 stateless: true，会导致 session 机制失效、CSRF 校验跳过，但 cookie 仍可能被发送，引发意料外的冲突。
- 正确做法是单独定义一个
api防火墙，启用stateless: true，并搭配json_login或自定义guard认证器 -
stateless: true不代表“不鉴权”，只是不依赖 PHP session；token 还是要解析、验证、关联 User 对象 - 别忘了在
access_control中为/api/明确指定用哪个 firewall，例如：firewall: api（Symfony 6.2+ 支持该字段），否则仍走默认 firewall
最常被忽略的一点：修改 security.yaml 后，开发环境下缓存可能不自动更新，php bin/console cache:clear 必须执行，否则所有配置改动都像没改一样。
