本文详解 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，而是前后端契约理解偏差的经典案例。
