csrf token校验失败抛出csrftokenmismatchexception，表明前后端token不一致，根源在于token生成、传递或校验断层；需确保前端正确获取并携带token、检查session/token存储是否重置、确认csrf配置未被禁用，并返回403而非捕获处理。
CSRF Token 校验失败时抛出 CsrfTokenMismatchException，通常说明客户端提交的 token 与服务端当前会话中存储的 token 不一致。这不是一个“异常需要捕获处理”的业务错误，而是安全机制主动拦截的结果，核心问题在于 token 的生成、传递或校验环节出现了断层。
确保前端正确获取并携带 CSRF Token
Spring Security 默认通过 _csrf 参数（表单）或 X-CSRF-TOKEN 请求头（AJAX）校验 token。常见疏漏包括：
- 未在页面首次加载时从响应中提取 token（如 Thymeleaf 中用
th:attr="csrf-token=${_csrf.token}"，或 JS 中解析 meta 标签） - 表单提交时遗漏
<input type="hidden" name="_csrf" th:value="${_csrf.token}"> - AJAX 请求未设置请求头：
headers.set('X-CSRF-TOKEN', tokenValue)（注意大小写和空格） - 使用了 Spring Security 的默认 cookie 名
XSRF-TOKEN，但前端未按约定读取并放入请求头（需配合CookieCsrfTokenRepository.withHttpOnlyFalse()配置）
检查 Session 或 Token 存储是否被意外重置
CSRF token 默认绑定到 HttpSession。以下情况会导致服务端 token 变更，而前端仍用旧值：
- 用户登录/登出后 session 被重建，但前端未刷新 token（需在登录成功响应中返回新 token）
- 多个标签页并发操作，一个页面触发了 token 更新（如提交表单），其他页面仍持有旧 token
- 集群环境下未共享 session（如 Redis session 未配置或失效），导致不同节点生成不同 token
- 手动调用了
CsrfTokenRepository.saveToken(null, request, response)清除了 token
确认 CSRF 配置未被覆盖或禁用
某些场景下开发者可能无意中关闭或干扰了默认机制：
- 自定义
WebSecurityConfigurerAdapter（旧版）或SecurityFilterChain（新版）中显式调用了.csrf().disable() - 对特定路径（如 API 接口）误配了
.requestMatchers("/api/**").csrf(Customizer.withDefaults())，但未实际启用 - 使用了
CookieCsrfTokenRepository却没配http.csrf().csrfTokenRepository(...)，导致 fallback 到 session-based 方式，前后端不匹配
调试建议：快速定位断点
在开发阶段可临时添加日志或断点辅助排查：
- 在 controller 方法前加
@ModelAttribute注入CsrfToken，打印其getToken()值，对比前端发送的值 - 开启 debug 日志：
logging.level.org.springframework.security.web.csrf=DEBUG，观察 token 加载、匹配过程 - 用浏览器开发者工具检查 Network → Request Headers 和 Response Cookies，确认
XSRF-TOKEN是否存在且被正确读取 - 验证是否为跨域请求：若前端域名与后端不一致，需额外配置 CORS 并允许凭据（
withCredentials = true），否则 cookie 不会发送
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
