HTTP 405错误：方法不被允许，到底哪里出问题了？

你点一下提交按钮，页面弹出「405 Method Not Allowed」，浏览器地址栏还干干净净没跳转——这事儿挺常见，但很多人第一反应是“后端崩了？”其实未必。它不是服务器挂了，而是服务器在说：“你想干的事，我不让干。”

405不是bug，是明确的拒绝

HTTP状态码405表示客户端用了服务器不支持的请求方法。比如你用POST往一个只接受GET的接口发数据，或者用DELETE去删一个压根没开放删除权限的资源，服务器就会干脆利落地回一个405，并在响应头里带上 Allow: GET, HEAD 这样的字段，告诉你：“我只认这几个方法。”

真实场景里，这些操作最容易踩坑

前端写表单时没注意method属性：

<form action="/api/user" method="post">
  <input type="text" name="name">
  <button type="submit">提交</button>
</form>

又比如调API时手滑写错方法：

fetch('/api/config', { method: 'PUT' }) // 实际接口只支持GET

curl -X POST https://example.com/status

怎么快速定位？看三样东西

打开浏览器开发者工具 → Network标签页 → 找到报405的那条请求 → 点开它，重点看：
① Headers 里的 Request Method（你发的是啥）；
② Response Headers 里的 Allow 字段（服务器认啥）；
③ Preview 或 Response 标签里有没有返回提示信息（有些后端会多写一句“请使用GET”）。

后端同学也常忽略的小细节

Spring Boot里写了 @GetMapping("/list")，但前端偏要POST过来，就405；Django里只定义了 get() 方法，没写 post()，同理；Nginx反向代理时如果配了 limit_except GET { deny all; }，其他方法也会被拦下。

还有种情况：API网关或WAF开了严格方法校验，比如只放行GET、HEAD，你调个OPTIONS探测接口，也被拒——这时候得去查网关策略，不是代码问题。

别硬刚，先对齐“能干啥”

遇到405，别急着重启服务或翻日志大海捞针。先确认三件事：
• 接口文档写的允许方法是哪些？
• 你当前发起的请求方法是哪个？
• 响应头里的 Allow 字段列了哪些？
三者一对，基本立马知道是前端写错了、后端漏配了，还是中间件挡住了。