laravel中仅get路由无需csrf验证，post、put、patch、delete等非get路由必须携带csrf令牌，否则请求被拒绝；表单提交需用_method字段伪造http方法，且对应路由须注册为post。
路由定义和请求方法不匹配
这是最常见原因：你发了一个 POST 请求，但路由只注册了 GET；或者用了 Route::get() 定义接口，前端却用 fetch 发 PUT。Laravel 的 RouteCollection 会严格比对方法列表，不匹配就直接抛 MethodNotAllowedHttpException，连中间件都不会进。
检查方式很简单：
- 运行
php artisan route:list，确认目标 URL 对应的Method列是否包含你实际使用的请求方法 - 注意大小写：
post和POST在 Laravel 中等价，但拼错成Post或漏写方法数组（如methods=['post']写成methods='post'）会导致注册失败 - 别忽略隐式路由：用
Route::resource()时，/users/{id}默认支持GET（显示）和PUT/PATCH（更新），但不支持POST—— 如果你往这个 URL 发POST，就会 405
表单提交没带 CSRF 令牌或 method spoofing 失败
Laravel 要求所有非 GET 表单必须携带 _token，且如果想用 PUT/DELETE，还得靠 _method 字段“伪装”。一旦缺失或值非法（比如写成 _method=putt），Laravel 在解析阶段就会拒绝该请求，返回 405（不是 419）。
典型错误场景：
-
<form method="POST"></form>里漏了{{ csrf_field() }}或手动写的<input name="_token" value="{{ csrf_token() }}"> - 想发
PUT，但只写了<input name="_method" value="PUT">，却没配POST路由 —— Laravel 要求必须先走POST，再靠中间件转义，所以路由得是Route::post(...)，不能是Route::put(...) - CSRF token 过期或被清空（比如多标签页反复刷新导致 session 重置），此时请求可能卡在验证前就被拦截
控制器中 authorize() 返回 false 且未定义对应 HTTP 方法
如果你用了 Laravel 的表单请求验证类（FormRequest），它的 authorize() 方法默认返回 false。一旦返回 false，Laravel 不会继续执行验证或控制器逻辑，而是直接抛出 MethodNotAllowedHttpException —— 注意，这不是权限拒绝（403），而是框架误判为“该请求根本不该到达这里”，于是按方法不匹配处理。
这种情况特别隐蔽，因为日志里看不到明确提示，堆栈也停在 RouteCollection.php。排查要点：
- 检查你传入控制器的
Request类是否继承自FormRequest - 确认该类的
authorize()方法是否显式返回true，或删掉该方法（默认行为是true） - 别混淆
authorize()和策略类 —— 这里只是表单请求类自己的授权钩子
中间件提前终止或重定向到不支持的方法
某些中间件（比如验证失败后的自动重定向）会强制跳转到一个 GET 地址。但如果你的原始表单是 POST 到 /submit，而验证失败后重定向到了 /submit（仍是同 URL），浏览器会以 GET 访问它 —— 如果这个 URL 没配 GET 路由，就会触发 405。
常见于：
- 自定义验证逻辑里手动
return redirect()->back()，但没指定 fallback 路由，回退到当前 URL，而该 URL 只支持POST - 用了
$this->validate()但没配GET路由，失败后 Laravel 自动重定向，结果撞上 405 - 中间件里调用了
abort(405)或类似逻辑（虽然少见，但自定义中间件可能这么干）
真正棘手的是第三种情况：authorize() 返回 false 导致的 405 很难从日志定位，它不报错信息、不打 trace，只安静地抛异常。遇到 “No message” 的 MethodNotAllowedHttpException，优先翻控制器里用的 Request 类，而不是急着改路由或加 token。
