本文详解 jquery 中 ajax post 请求意外触发 get 方法的常见原因，重点分析 `contenttype: “application/json”` 与表单序列化数据不兼容的问题，并提供安全、可靠且符合 rest 规范的修复方案。
在使用 jquery 发起 ajax 请求时，开发者常遇到一个隐蔽却高频的问题：明明指定了 method: “POST”，服务端却报错 “GET request is not supported” 或返回 405 Method Not Allowed。这并非 jQuery 发送了 GET 请求，而是服务端根本未收到预期的 POST 请求体，反而收到了一个空或无效的 POST，继而因路由/框架默认行为（如 spring mvc、ASP.NET Core 或 express 的 REST 路由约束）回退到处理 GET 的逻辑，或直接拒绝请求。问题根源往往不在 http 方法本身，而在请求载荷（payload）与内容类型的不匹配。
? 核心问题定位：json.stringify() + serializeArray() + contentType: “application/json” 的组合陷阱
观察原始代码：
var formData = JSON.stringify($("#form-titulo").serializeArray()); $.ajax({ method: "POST", url: "/titulos/editar/" + $("#codigoTitulo").val(), data: formData, contentType: "application/json; charset=utf-8", // ⚠️ 关键问题点 // ... });这里存在两个关键矛盾：
- serializeArray() 返回的是 JavaScript 数组对象（形如 [{“name”:”title”,”value”:”ABC”},{“name”:”author”,”value”:”John”}]），它本身是合法的 JS 数据结构；
- 但 JSON.stringify() 将其转为 JSON 字符串后，再以 contentType: “application/json” 发送，意味着后端必须解析 JSON 并期望接收到一个标准 JSON 对象/数组；
- 而绝大多数后端框架（如 spring boot 的 @RequestBody、ASP.NET Core 的 [FromBody]、Express 的 body-parser.json()）默认要求 JSON 的顶层是对象 {}，而非数组 [] —— 否则解析失败，导致请求体为空，框架可能忽略 POST 体并降级处理，甚至某些中间件会因解析异常而拒绝请求或触发 400/405。
更严重的是：许多后端 REST API 设计中，/titulos/editar/{id} 这类路径明确只接受 POST（或 PUT/PATCH）携带结构化数据，而对无 body 的 POST 或格式错误的 POST 直接返回 405，让前端误以为“发成了 GET”。
✅ 推荐解决方案：避免手动 JSON 序列化，改用原生表单提交语义
最稳健、兼容性最强的做法是放弃 JSON.stringify()，直接传递 serializeArray() 或更优的 serialize() 结果，并使用 application/x-www-form-urlencoded（jQuery 默认 Content-Type）：
function doPost() { const id = $("#codigoTitulo").val(); const formData = $("#form-titulo").serialize(); // ✅ 返回 "title=ABC&author=John" 字符串 $.ajax({ method: "POST", url: `/titulos/editar/${id}`, data: formData, // 自动设置为 application/x-www-form-urlencoded success: function(response) { console.log("Título atualizado com sucesso:", response); alert("Edição realizada!"); }, error: function(jqXHR, textStatus, errorThrown) { console.error("Erro ao editar título:", jqXHR.status, jqXHR.responseText); alert(`Falha: ${textStatus} - ${errorThrown}`); } }); }? 提示：$(“#form-titulo”).serialize() 比 serializeArray() 更适合表单提交，它生成标准 URL 编码字符串，后端可直接绑定到 DTO/Model（如 Spring 的 @ModelAttribute），无需额外 JSON 解析逻辑。
? 替代方案：若后端强制要求 JSON 格式（需显式支持数组）
仅当后端 API 明确约定接收 JSON 数组（且已配置允许解析 JSON 数组）时，才应使用 JSON 方式。此时必须确保：
- 后端能正确反序列化 JSON 数组（例如 Spring Boot 需配置 spring.jackson.deserialization.read-unknown-enum-values-as-NULL=false 并使用 List 接收）；
- 前端发送的是合法 JSON 对象，而非数组（推荐重构为对象）：
function doPost() { const id = $("#codigoTitulo").val(); const formArray = $("#form-titulo").serializeArray(); // 转换为扁平对象（更符合 REST 实践） const formDataObj = {}; formArray.forEach(item => { formDataObj[item.name] = item.value; }); $.ajax({ method: "POST", url: `/titulos/editar/${id}`, data: JSON.stringify(formDataObj), // ✅ 顶层是对象 {} contentType: "application/json; charset=utf-8", success: function(response) { alert("Sucesso!"); }, error: function(jqXHR, textStatus, errorThrown) { alert("Erro: " + textStatus); } }); }⚠️ 重要注意事项
- 不要混用 serializeArray() 和 JSON.stringify() 除非后端明确支持 JSON 数组输入 —— 这是本问题的直接诱因；
- $.post() 是 $.ajax({ method: “POST” }) 的语法糖，但它默认使用 application/x-www-form-urlencoded，因此答案中给出的 $.post(…) 方案本质是规避了 JSON 内容类型问题，值得采纳；
- 始终校验 $(“#codigoTitulo”).val() 是否为空，避免生成非法 URL 如 /titulos/editar/；
- 现代项目建议升级 jQuery 至 3.x+，并优先考虑 fetch() API，但迁移前需确认浏览器兼容性及 FormData 支持；
- 服务端日志是黄金线索：检查实际收到的 Content-Type、Content-Length 及原始请求体，比前端断点更可靠。
通过修正数据格式与内容类型的匹配关系，即可彻底解决“AJAX 声称 POST 却被服务端拒收”的问题——这不是 jQuery 的 bug，而是前后端契约理解偏差的经典案例。