laravel 表单未加 @csrf 报 419 错误，因框架默认启用 csrf 防护，所有非安全请求须携带有效 token；blade 中需写 @csrf，ajax 应读取 meta 标签并设 x-csrf-token 头。
为什么 Laravel 表单没加 @csrf 就报 419 错误
因为 Laravel 默认开启全局 CSRF 防护，所有 POST、PUT、PATCH、DELETE 请求都必须携带有效的 CSRF token，否则中间件 VerifyCsrfToken 会直接返回 419 页面。这不是配置漏了，而是框架的默认安全策略在起作用。
常见错误现象：
• 提交自定义 HTML 表单（没用 Blade）时 419
• AJAX 请求没带 X-CSRF-TOKEN 头，返回 419 或 403
• 在 Vue/React 单页应用中复用 Laravel 后端，token 过期或未刷新
- Blade 模板里必须写
@csrf（它会生成隐藏 input：<input type="hidden" name="_token" value="...">） - AJAX 请求需从
<meta name="csrf-token" content="...">读取值，并设请求头X-CSRF-TOKEN - 不要手动拼接
_token值——session 中的 token 是绑定 session ID 的，硬编码会失效
VerifyCsrfToken 中间件怎么排除特定路由
有些接口本就不该走 CSRF 校验，比如 Webhook 接收地址、API 端点（尤其用 API Token 或 JWT 认证时）。Laravel 允许白名单排除，但得小心路径匹配逻辑。
使用场景：
• 第三方服务回调（如 Stripe、微信支付）
• 前后端分离项目中纯 API 路由
• 内部系统间 HTTP 调用（已通过 IP 或签名鉴权）
- 在
app/Http/Middleware/VerifyCsrfToken.php的$except数组里填路径，支持通配符：'api/webhook/*'、'admin/export' - 路径匹配基于路由定义的 URI，不是完整 URL，不包含域名或 query string
- 排除后该路由彻底跳过 token 校验——别误加到登录、密码重置等敏感操作上
- 如果用
Route::middleware('web')包裹了 API 路由，即使写了$except也可能因中间件顺序问题仍被拦截；确认路由属于api中间件组更稳妥
CSRF token 刷新时机和失效原因
Laravel 的 CSRF token 绑定当前 session，每次 session 写入（比如登录、regenerate）都会刷新。但用户无感知的失效更常来自缓存或并发请求。
常见错误现象：
• 表单页面打开很久再提交，报 419
• 同一账号在两个标签页同时操作，一个成功一个失败
• 使用 Nginx 缓存了含 @csrf 的 Blade 页面，token 固定不变
- token 存在 session 中，默认有效期 = session 生命周期（通常 2 小时），不受
cache.ttl影响 - Blade 模板不能被静态缓存——Nginx 或 CDN 缓存含
@csrf的 HTML 会导致所有用户拿到同一个旧 token - Vue/React 前端若从服务端首次获取 token 后长期复用，需监听 419 响应并主动刷新（调用
/sanctum/csrf-cookie或重新拉首页） - 不要在 JS 里用
document.querySelector('input[name=_token]').value动态取值后长期缓存——它不会自动更新
API 场景下要不要关 CSRF？关了安不安全？
要关，但不是靠关中间件，而是靠路由分组。Laravel 的 api 中间件组默认不启用 VerifyCsrfToken，这是设计使然——API 应该用 stateless 认证（如 Bearer Token、JWT），CSRF 对无 cookie 的请求无效。
容易踩的坑：
• 把 API 路由写在 routes/web.php 里，结果被 web 中间件包裹，意外触发 CSRF 校验
• 用 auth:sanctum 却把前端 Cookie 模式和 Token 模式混用，导致 token 不一致
• 在 API 路由里手动加 ->middleware('web')，等于自己绕回 CSRF 流程
- API 路由必须定义在
routes/api.php，且不显式加web中间件 - 如果必须用
web组但又想跳过 CSRF，优先走$except白名单，而不是删中间件——避免影响其他路由 - CSRF 防护只对 cookie 认证有效；用 API Token 时，攻击者拿不到 token，CSRF 自然无意义——但前提是真正不用 cookie
token 绑定 session 这个机制本身没问题，问题多出在缓存、路由分组错配、或前端没理解 token 的生命周期。盯住 session 和中间件这两层，比调参数更管用。
