Ajax 请求被错误地发送为 GET 而非 POST 的原因与解决方案

本文详解 jquery ajax post 请求被意外降级为 get 的常见原因（如 contenttype 与 data 类型不匹配、服务器端路由限制等），并提供兼容性更强的 $.post() 替代方案及调试建议。

在使用 jQuery 1.10.2 进行 Ajax 请求时，若明确指定 method: "POST" 却仍收到类似 “GET request not supported” 的错误（例如 Spring Boot 报 Request method 'GET' not supported 或 Express 报 405 Method Not Allowed），这通常并非浏览器真正发出了 GET 请求，而是后端未正确识别请求为 POST —— 根本原因往往在于 前端请求配置与后端期望不匹配，尤其体现在数据格式和 Content-Type 上。

? 问题定位：为什么 method: "POST" 失效？

你当前的代码存在一个关键矛盾：

var formData = JSON.stringify($("#form-titulo").serializeArray());
// → 得到的是字符串，例如：'[{"name":"titulo","value":"ABC"},{"name":"valor","value":"100"}]'

$.ajax({
  method: "POST",
  url: "/titulos/editar/" + $("#codigoTitulo").val(),
  data: formData, // ← 字符串
  contentType: "application/json; charset=utf-8", // ← 声明为 JSON
  // ...
});

✅ 表面看完全正确：指定了 POST、设置了 JSON Content-Type、传了 JSON 字符串。
⚠️ 但隐患在于：后端控制器是否真的以 @RequestBody 接收 JSON 数组？
❌ 如果后端是传统表单接收方式（如 Spring MVC 的 @ModelAttribute、或 Express 的 body-parser.urlencoded()），它只会解析 application/x-www-form-urlencoded 数据，而忽略 application/json 请求体 —— 此时服务器可能因无法解析而 fallback 到空/默认行为，甚至某些框架（如旧版 Spring）在未匹配到 @RequestBody 方法时，会将请求误判为无效 POST 并返回 405，或更隐蔽地被中间件重定向/降级。

此外，jQuery 1.10.2 对 contentType: "application/json" 的处理较严格：若 data 是字符串，它不会自动添加 Content-Length 或做额外序列化；而部分后端（尤其未显式启用 JSON 支持时）可能直接拒绝该请求，导致日志中看似“没收到 POST”。

✅ 推荐解决方案：优先使用语义明确的 $.post()

正如答案所建议，改用 $.post() 是更简洁、鲁棒的选择——它默认使用 application/x-www-form-urlencoded，与 HTML 表单原生行为一致，且无需手动 JSON.stringify：

OmniAudio

OmniAudio 是一款通过 AI 支持将网页、Word 文档、Gmail 内容、文本片段、视频音频文件都转换为音频播客，并生成可在常见 Podcast ap

下载

function doPost() {
  const data = $("#form-titulo").serialize(); // ← 直接生成 key=val&key2=val2 字符串
  $.post("/titulos/editar/" + $("#codigoTitulo").val(), data)
    .done(function(response) {
      console.log("Success:", response);
      alert("Título atualizado com sucesso!");
    })
    .fail(function(jqXHR, textStatus, errorThrown) {
      console.error("Error:", textStatus, errorThrown);
      alert("Erro ao editar título: " + (jqXHR.responseJSON?.message || textStatus));
    });
}

? 关键改进：使用 .serialize()（非 .serializeArray()）→ 输出标准表单编码字符串，兼容 urlencoded 解析器；移除 contentType → 让 jQuery 自动设为 application/x-www-form-urlencoded; charset=UTF-8；使用链式 .done() / .fail() 替代 success/error（后者在 jQuery 3.0+ 已弃用，1.10.2 中虽可用，但链式更清晰）。

? 其他调试与加固建议

1. 验证后端路由是否支持 POST
   确保服务端对应路径 /titulos/editar/{id} 明确声明了 @PostMapping（Spring）或 app.post(...)（Express），且无前置中间件（如身份验证拦截器）意外重定向或修改 method。

2. 检查浏览器开发者工具 Network 面板

   • 查看实际发出的请求：确认 Request Method 确实是 POST；
   • 检查 Request Headers 中 Content-Type 是否为预期值；
   • 查看 Payload 标签页内容是否符合后端接收格式（如 JSON 结构 or form-data 键值对）。

3. 如必须传 JSON，请前后端严格对齐

   // 前端（保持 JSON）
   $.ajax({
     type: "POST",
     url: "/titulos/editar/" + id,
     contentType: "application/json",
     data: JSON.stringify({
       titulo: $("#titulo").val(),
       valor: $("#valor").val()
       // ⚠️ 不要 serializeArray → 构造明确对象
     }),
     dataType: "json"
   });

   // 后端（Spring 示例）
   @PostMapping("/titulos/editar/{id}")
   public ResponseEntity update(@PathVariable String id, @RequestBody TituloDTO dto) { ... }

✅ 总结

通过统一数据格式与后端约定，并优先选用高语义化的封装方法（如 $.post），即可彻底规避“Ajax 发送 GET 而非 POST”的典型陷阱。