laravel 的 xsrf-token 响应头由 verifycsrftoken 中间件在 session 启动后自动生成，内容为加密的 session token；前端需确保同源且 xsrf-token cookie 可被 javascript 读取（httponly=false），axios 才自动将其设为 x-xsrf-token 请求头。
CSRF token 从哪来：Laravel 的 XSRF-TOKEN 响应头怎么生成
前后端分离时，csrf_token() 函数不能直接用在前端模板里，得靠后端把 token 注入到响应头中。Laravel 默认会在每次响应中自动设置 XSRF-TOKEN 响应头（前提是启用了 VerifyCsrfToken 中间件且 session 已启动）。
这个 token 实际是加密后的 session token，由 Illuminate\Cookie\Middleware\EncryptCookies 加密，前端拿到后需存入 cookie（通常叫 XSRF-TOKEN），axios 等库会自动读取它并附在 X-XSRF-TOKEN 请求头里。
- 确保
APP_KEY已正确配置，否则加密失败，XSRF-TOKEN可能为空或解密异常 - 如果用 API 路由（
api/*），默认不启用 CSRF 验证——必须手动把路由移到web中间件组，或显式加\App\Http\Middleware\VerifyCsrfToken::class -
XSRF-TOKENcookie 默认是httpOnly: false，但 Laravel 7+ 默认设为true；若前端需要读取，得在config/session.php中设'http_only' => false，或改用其他方式传 token
前端怎么发请求：axios 自动带 X-XSRF-TOKEN 的前提条件
axios 不是“默认就带”，它只在满足两个条件时才自动读取 XSRF-TOKEN cookie 并设请求头：
- 请求 URL 和当前页面同源（协议 + 域名 + 端口一致）
-
XSRF-TOKENcookie 存在且可被 JavaScript 访问（即httpOnly: false）
常见错误现象：419 Page Expired 或 403 Forbidden，往往是因为前端压根没发 X-XSRF-TOKEN 头——检查浏览器开发者工具的请求头，确认是否出现该字段。
如果跨域开发（比如前端跑在 http://localhost:5173，后端在 http://localhost:8000），axios 不会读 cookie，此时必须手动处理：
axios.defaults.headers.common['X-XSRF-TOKEN'] = document.cookie
.split('; ')
.find(row => row.startsWith('XSRF-TOKEN='))
?.split('=')[1];
为什么 sanctum/csrf-cookie 路由必须先调一次
Laravel Sanctum 的 /sanctum/csrf-cookie 不是“获取 token”，而是触发一次 session 初始化 + 设置 XSRF-TOKEN cookie。很多团队跳过这步，直接发 POST，结果 419。
- 该路由必须用 GET 请求，且走
web中间件（不能走api） - 调用后，服务端会写入 session，并返回含
XSRF-TOKEN的响应头；浏览器自动存为 cookie - 如果前端用 fetch，记得设
credentials: 'include'，否则 cookie 不发送，后端收不到 session ID，无法关联 token - 该接口返回 204，无 body，别指望它返回 JSON token 字段——它只管种 cookie
绕过 CSRF 的典型误操作：哪些请求真的不需要 token
不是所有 POST/PUT/DELETE 都要 CSRF token。Laravel 默认只对非 GET、非 HEAD 请求校验，但真正决定是否跳过的是 VerifyCsrfToken::except() 和请求来源。
-
api/*路由默认不校验 CSRF —— 因为设计上认为 API 是无状态、靠 token（如 Sanctum/Bearer）鉴权的 - 如果你混用 session 登录和 API 调用（比如用
Auth::user()在 API 控制器里），又没手动加中间件，CSRF 就不会生效，看似“没问题”，实则裸奔 - 静态资源（
.js、.css）、健康检查（/health）等路径常被误加进except，结果连登录表单提交都绕过了防护
CSRF 防护的关键不在“有没有 token”，而在“session 是否可信绑定”。前后端分离下最容易漏掉的，是忘了让前端主动触发一次带 session 的初始化请求，以及混淆了 web 和 api 中间件的语义边界。
