PUT请求在Gin中必须用r.PUT()显式注册，与GET、POST严格区分；路径参数用c.Param()获取，查询参数用c.Query()，请求体需调用ShouldBindJSON或ShouldBind解析，不可用c.PostForm；成功应返回200或204状态码。
PUT 请求在 Gin 中和 GET、POST 一样是原生支持的，但实际使用中容易因语义理解偏差或参数处理方式错位导致逻辑出错。
PUT 路由注册必须用 r.PUT()，不能混用 r.POST()
虽然 HTTP 协议不禁止用 POST 模拟更新操作，但 Gin 的路由匹配是严格区分方法的：r.POST("/user/:id") 和 r.PUT("/user/:id") 是两条完全独立的路由。如果前端发的是 PUT，而你只写了 POST 路由，会直接返回 404。
- 正确写法：
r.PUT("/users/:id", handler)—— 明确声明接受 PUT - 别依赖
r.Any()或r.Match()来“兜底”，它们会掩盖方法误用问题 - 调试时可用
curl -X PUT http://localhost:8080/users/123验证是否命中
PUT 请求体默认不自动解析表单，要主动调用 BindJSON 或 Bind
Gin 不像某些框架那样对 PUT 做特殊处理。它把请求体当作原始数据流，c.PostForm("xxx") 在 PUT 中返回空字符串——因为 PostForm 只读 application/x-www-form-urlencoded 的 body，且仅对 POST 方法做隐式兼容。
- RESTful 场景下，PUT 通常带 JSON：
c.ShouldBindJSON(&user) - 若客户端发的是表单（
Content-Type: application/x-www-form-urlencoded），需用c.ShouldBind(&user)，它会按 Content-Type 自动选择解析器 - 绝对不要用
c.DefaultQuery或c.Query读 PUT 的 body 参数，它们只处理 URL 查询字符串
路径参数和查询参数共存时，Param 和 Query 要分开取
比如路由定义为 r.PUT("/users/:id?force=true")，这里的 :id 是路径参数，force 是查询参数，Gin 不会自动合并。
- 取路径参数：
id := c.Param("id")—— 必须和路由定义中的 key 一致 - 取查询参数：
force := c.Query("force")或c.DefaultQuery("force", "false") - 注意：
c.Param("force")永远为空，因为force不在路径模板里
PUT 处理函数里别漏掉状态码和明确响应
PUT 语义是“全量替换”，HTTP 规范建议成功时返回 200 OK 或 204 No Content。Gin 默认不设状态码，靠 c.JSON() 等方法隐式设为 200，但显式写更安全。
- 推荐写法：
c.JSON(http.StatusOK, gin.H{"ok": true, "id": id}) - 若无响应体，用
c.Status(http.StatusNoContent)比c.String(204, "")更符合语义 - 错误时务必提前 return，避免后续逻辑执行：例如
if err != nil { c.AbortWithStatusJSON(http.StatusBadRequest, gin.H{"error": err.Error()}); return }
c.PostForm 也无效；还有人把路径参数名写错，比如路由是 /posts/:post_id 却调用 c.Param("id")，结果拿到空字符串还继续往下跑，最后数据库报错才暴露问题。 
