symfony 6 标准表单默认启用 csrf 保护，form_start() 自动注入 _token 字段；手动渲染需用 csrf_token('authenticate') 插入隐藏字段，验证时 id 必须一致，禁用或修改字段名将导致 403 错误。
默认已开启，不需要额外操作 —— 只要你用的是 Symfony 6 的标准表单组件（FormType + form_start()），CSRF 就自动生效，连配置都不用改。
为什么 form_start() 渲染的表单自带 CSRF 字段？
Symfony 表单组件在构建时默认启用 CSRF 保护。它会调用 CsrfTokenManager 生成一个与当前用户 session 绑定的令牌，并通过 csrf_token() Twig 函数注入到隐藏字段中。
- 字段名固定为
_token，不是csrf_token或自定义名 - 该行为由表单类型中的
csrf_protection: true（默认值）控制 - 底层依赖
symfony/security-csrf，但该组件在 Symfony 6 中已整合进核心安全流程，无需单独 require
手动渲染表单时怎么加 CSRF 字段？
如果你不用 form_start()，而是手写 HTML 表单（比如 AJAX 提交或纯前端控制），就必须自己插入合法的 CSRF 令牌：
- 在 Twig 模板里用：
<input type="hidden" name="_token" value="{{ csrf_token('authenticate') }}"> -
'authenticate'是 token 的“意图 ID”，可自定义，但前后端必须一致；常用值有'authenticate'、'comment'、'delete'等语义化标识 - 后端验证时需用相同 ID 调用
$csrfTokenManager->isTokenValid(new CsrfToken('authenticate', $submittedToken)) - 别用
csrf_token('default')—— 这个 ID 已被弃用，Symfony 6+ 不再识别
禁用或调整 CSRF 的常见错误
除非有明确理由（如 API 接口、第三方回调），否则不建议关掉 CSRF。但如果真要调，注意这些坑：
- 在
FormType中设->setOption('csrf_protection', false)：只影响该表单，但会彻底移除防护，且不会警告 - 全局关闭？别干这事。
framework.csrf_protection.enabled: false在 Symfony 6 中已被移除，设了也无效 - 修改
csrf_field_name（比如改成my_token）：会导致form_start()渲染的字段名和验证逻辑不匹配，直接 403 - 在非 session 场景（如无状态 API）下硬塞 CSRF：会因找不到用户上下文而抛出
InvalidCsrfTokenException
真正容易被忽略的是：CSRF 令牌绑定的是 **当前用户的 session ID**，不是登录态本身。如果用户没 session（比如刚打开首页还没登录），csrf_token() 仍能生成值，但验证时会失败 —— 因为没关联的 session 存储上下文。这种情况下，要么先触发 session 启动（如访问一个带 session 的路由），要么换用无状态方案（如 JWT + 签名 nonce）。
