ValidateAntiForgeryToken 有效需Token生成、传输、校验闭环完整；常见400错误主因是Token未生成或未传入，如漏写@Html.AntiForgeryToken()、GET请求误用、前后端分离时未配Header传递、SameSite=None未配Secure、AJAX未带credentials或Token过期。
ValidateAntiForgeryToken 不是加了就万事大吉——它依赖底层 Token 生成、传输和校验链的完整闭环。ASP.NET Core 默认启用防伪机制，但多数项目在迁移、AJAX 场景或前后端分离架构下会掉进几个关键坑。
为什么 [ValidateAntiForgeryToken] 总报 400 错误？
这是最常遇到的现象：表单提交直接返回 Bad Request - InvalidAntiForgeryToken，但代码看起来完全正确。
- 根本原因不是属性没加，而是 Token 没被正确生成或没传到后端——比如视图里漏了
@Html.AntiForgeryToken()，或用了form[method="get"]却对 GET 请求也加了该特性（[ValidateAntiForgeryToken]只应作用于非幂等操作，如 POST/PUT/DELETE） - 前后端分离时（如 Vue/React 调用 ASP.NET Core API），
@Html.AntiForgeryToken()不生效，必须改用 Header 方式：服务端需配置services.AddAntiforgery(options => options.HeaderName = "X-XSRF-TOKEN")，前端从 Cookie（通常是XSRF-TOKEN）读值并设为请求头 - 若启用了
SameSite=None的 Cookie（如跨域场景），但没同时设置Secure=true，浏览器会拒绝发送该 Cookie，导致 Token 获取失败
AddAntiforgery 配置项差异影响 Token 行为
默认配置下 Token 存在 Session 或内存中，但生产环境常需调整：
-
options.Cookie.SameSite = SameSiteMode.Strict：最安全，但可能阻断正常跨站跳转（如 OAuth 回调）；Lax是更实用的折中选择 -
options.Cookie.HttpOnly = false：必须设为false，否则前端 JS 无法读取XSRF-TOKENCookie（HttpOnly是安全特性，但防 CSRF Token 场景下需让 JS 可读） -
options.FormFieldName和options.HeaderName可自定义字段名，但前后端必须严格一致；改了HeaderName却没同步前端 AJAX 设置，就会验证失败
AJAX 请求怎么带 Token 才不被拦截？
不能只靠 $.ajaxSetup 或全局 axios interceptor——得确认 Token 来源是否实时、是否过期。
- Token 不是静态值：每次新会话或调用
ITokenProvider.GenerateTokenAsync都会刷新，所以前端不应缓存旧值 - 推荐做法：首次加载页面时，由服务端在响应 Cookie 中写入
XSRF-TOKEN（ASP.NET Core 自动做），前端用document.cookie.match(/XSRF-TOKEN=([^;]+)/)?.[1]提取，并在每个 POST/PUT 请求头中带上X-XSRF-TOKEN: xxx - 注意：Fetch API 不自动携带 Cookie，需显式加
credentials: 'include'，否则 Cookie 不发，Token 就丢了
自定义中间件绕过验证时，容易忽略的副作用
有些接口（如 WebHook、第三方回调）确实需要跳过验证，但直接在控制器上加 [IgnoreAntiforgeryToken] 很危险——它只是跳过检查，不解决 Token 缺失引发的其他问题。
- 如果该 Action 同时被正常用户页面调用（比如管理后台点“重试 WebHook”），跳过验证就等于打开 CSRF 大门
- 更稳妥的做法是：用策略模式区分入口，例如通过路由前缀
/api/webhook/+ 自定义授权策略，在中间件里判断来源 IP 或签名，而非粗暴跳过 - 切记：
[IgnoreAntiforgeryToken]不能和[ValidateAntiForgeryToken]共存于同一 Action，后者会直接覆盖前者
Token 的生命周期和存储位置（内存 vs Redis）在分布式部署下必须对齐，否则负载均衡后请求落到不同节点，验证必然失败——这点在水平扩展时最容易被当成“玄学 Bug”排查半天。
