DELETE请求体参数后端收不到，因Gin默认不解析DELETE请求体，仅对POST/PUT自动解析；需显式调用ShouldBindJSON或自定义中间件启用解析，且须确保CORS预检允许DELETE方法。
为什么 DELETE 请求体里的参数后端收不到
因为 Express、Gin 等默认不解析 DELETE 请求的请求体（req.body），只对 POST 和 PUT 做了开箱即用的解析支持。Axios 发送 delete 时若用 { data: { id: 1 } }，数据确实进了请求体，但 Gin 不会自动解出来——它还在原始字节流里躺着。
常见错误现象：ctx.ShouldBindJSON(&v) 报错或 v 为空；打印 ctx.Request.Body 只看到一串未读取的二进制；c.PostForm("id") 返回空字符串。
- 不是 Axios 配置问题（
Content-Type: application/json正确即可） - 不是前端没发，是后端没“伸手去拿”
- Gin 默认中间件
gin.Default()里只挂了json、form、xml的绑定器，但仅对POST/PUT生效
在 Gin 中启用 DELETE 请求体解析的两种方式
核心思路：让 Gin 主动读取并解析 DELETE 的请求体，而不是依赖默认行为。必须显式调用绑定逻辑或注册中间件。
- 方式一：手动读取 + 解析（推荐用于简单场景）
func deleteHandler(c *gin.Context) { var req struct { ID int `json:"id"` } if err := c.ShouldBindJSON(&req); err != nil { c.JSON(400, gin.H{"error": "invalid JSON"}) return } // 此时 req.ID 已可用 } - 方式二：全局启用所有方法的 JSON 解析（需自定义中间件）
func jsonBodyMiddleware() gin.HandlerFunc { return func(c *gin.Context) { if c.Request.Method == "DELETE" || c.Request.Method == "PATCH" { c.Request.Header.Set("Content-Type", "application/json") } c.Next() } } // 然后在路由前 use 它，并确保 body 解析中间件在它之后 r.Use(jsonBodyMiddleware) r.Use(gin.Recovery()) r.Use(gin.Logger())注意：这仅是“骗过” Gin 的 method 判断，真正起作用的是后续的ShouldBindJSON调用，不是自动填充req.Body
DELETE 参数传法与后端接收的对应关系
前端传参方式决定后端怎么接，别混用。Axios 的 params 和 data 是两套机制，不能指望一个后端写法通吃。
立即学习“前端免费学习笔记（深入）”；
-
axios.delete("/api/item", { params: { id: 123 } })→ URL 变成/api/item?id=123→ 后端用c.Query("id")或c.ShouldBindQuery(&v) -
axios.delete("/api/item/" + id)→ URL 是/api/item/123→ 后端用c.Param("id")（需路由定义为/api/item/:id） -
axios.delete("/api/item", { data: { id: 123 } })→ 数据在请求体，Content-Type: application/json→ 后端必须用c.ShouldBindJSON(&v)显式解析
容易踩的坑：c.Bind() 在 DELETE 上可能静默失败；c.PostForm() 对 JSON 体完全无效；用 @RequestBody 的 Spring 写法思维套 Gin 会卡住。
Gin 处理预检 OPTIONS 请求时别漏掉 DELETE
如果前端带了非简单标头（比如 x-token、Authorization），浏览器会在 DELETE 前发一次 OPTIONS 预检。此时 Gin 若没在响应头里声明允许 DELETE，预检就失败，DELETE 根本发不出去。
正确做法（以中间件为例）：
func corsMiddleware() gin.HandlerFunc {
return func(c *gin.Context) {
origin := c.Request.Header.Get("Origin")
if origin != "" {
c.Header("Access-Control-Allow-Origin", origin)
c.Header("Access-Control-Allow-Methods", "GET,POST,PUT,DELETE,OPTIONS")
c.Header("Access-Control-Allow-Headers", "Content-Type,Authorization,x-token")
c.Header("Access-Control-Allow-Credentials", "true")
}
if c.Request.Method == "OPTIONS" {
c.AbortWithStatus(204)
return
}
c.Next()
}
}
关键点：Access-Control-Allow-Methods 必须显式包含 DELETE，不能只写 GET,POST,PUT；OPTIONS 响应必须返回 204，且不能继续走后续 handler。
复杂点在于：CORS 配置和请求体解析是两个独立问题，但常被一起触发。先解决预检失败，再解决参数收不到，顺序错了会浪费大量调试时间。
