这种明明在Postman里确认发的是POST请求，却被服务器判定为GET并返回405错误的情况真的很挠头，我帮你梳理几个最可能的排查方向和解决办法：

1. 检查是否存在请求重定向 #

有时候服务器会对请求URL做自动重定向（比如把/login重定向到/login/，或者HTTP强制跳转HTTPS），而重定向默认会把POST请求转换成GET。你可以查看Postman的「请求历史」，看看有没有3xx状态码的重定向响应；或者直接在请求里使用重定向后的最终URL再试一次。

2. 核对服务器端的路由方法配置 #

这是最常见的原因——你的登录端点可能只配置了支持GET方法，根本没开放POST权限。举两个主流框架的例子：

• 如果是JAX-RS（比如Jersey），要确保用了@POST注解：

@POST
@Path("/login")
@Consumes(MediaType.APPLICATION_JSON)
public Response login(UserCredentials credentials) {
    // 你的登录逻辑
}

• 如果是Spring Boot，要使用@PostMapping而非@GetMapping：

@PostMapping("/login")
public ResponseEntity<?> login(@RequestBody UserCredentials credentials) {
    // 你的登录逻辑
}

仔细检查服务器端代码，确认路由注解和请求方法完全匹配。

3. 排查CORS过滤器的细节问题 #

你说CORS过滤器看起来正常，但可能存在两个容易忽略的漏洞：

• 过滤器的执行顺序不对，导致它在路由匹配之前就修改了请求；
• 没有正确处理OPTIONS预检请求，或者返回的Allow头里没包含POST方法。
  确保你的CORS过滤器里有类似这样的配置：

response.setHeader("Allow", "POST, OPTIONS");

这样服务器才会明确告知客户端允许POST请求。

4. 重置Postman的请求配置 #

有时候Postman会缓存旧的请求设置，或者不小心添加了奇怪的请求头。你可以试试：

• 新建一个完全干净的请求，只填写URL、选择POST方法、添加正确的请求体，不要复用之前保存的请求；
• 检查请求头里有没有X-HTTP-Method-Override这类字段，有的话直接删除——这个头会强制服务器把POST请求当成其他方法处理。

5. 检查反向代理/网关的配置 #

如果你的服务器前面部署了Nginx、Apache这类反向代理，可能代理配置把POST请求转成了GET。比如Nginx里的rewrite规则出错，或者误加了proxy_method GET这类配置，都会导致请求被篡改。去核对代理的配置文件，确保POST请求被原样转发到后端服务器。

内容的提问来源于stack exchange，提问作者Peter Frisch