c.postform是获取post表单参数最直接安全的方式，仅从r.postform解析、不混入url参数、自动处理multipart、返回空字符串而非panic，并支持默认值；失败主因是content-type错误、结构体tag不匹配或body被提前读取。
c.PostForm 是唯一推荐的、直接且安全的获取方式，前提是请求头 Content-Type 必须是 application/x-www-form-urlencoded 或 multipart/form-data。用 c.Query 或 c.Param 去读表单字段，永远拿不到值。
为什么 c.PostForm 不能取到值
不是函数写错了，而是请求本身不满足前提条件。最常见现象是返回空字符串，但没报错，容易误判为逻辑问题。
- 前端发错
Content-Type：比如用fetch发表单却设了application/json；Postman 里选了 “raw” 而不是 “form-data” 或 “x-www-form-urlencoded” -
c.ShouldBind结构体 tag 写错：比如表单字段叫username，但结构体写了Username string `form:"user_name"`，绑定就失效 - body 被提前读取：中间件调了
c.GetRawData()或直接读了c.Request.Body，后续所有c.PostForm都返回空
c.PostForm 和 c.DefaultPostForm 的区别与使用场景
两者都只从 r.PostForm 解析，不混入 URL 查询参数，语义清晰。区别在于空值处理方式。
-
c.PostForm("name")没该字段时返回""，适合需要显式判断空值的逻辑（如if name == ""） -
c.DefaultPostForm("age", "18")没该字段时直接返回默认值，省去判空，适合有合理 fallback 的字段 - 数组字段必须用
c.PostFormArray("hobby")，不能用c.PostForm强转，否则会丢数据
混合参数（query + form + JSON）怎么一起收
Gin 不支持一次 c.ShouldBind 同时解析多种来源的数据。真实接口常要同时处理 URL 参数、表单字段、甚至 JSON body，必须手动拆开。
- URL 查询参数：用
c.Query("page")或c.DefaultQuery("limit", "20") - 表单字段：用
c.PostForm("title")，确保 Content-Type 正确 - JSON body：先
data, _ := c.GetRawData()，再json.Unmarshal(data, &v)；注意c.GetRawData()会消耗 body，不能再调c.PostForm - 别试图在同一个 handler 里既调
c.PostForm又调c.ShouldBindJSON—— body 只能读一次，后者会失败
文件上传时怎么取普通表单字段
c.PostForm 对 multipart/form-data 同样有效，不需要额外调 ParseMultipartForm。Gin 在第一次调 c.PostForm 或 c.FormFile 时会自动触发解析。
- 上传文件 + 文本字段（如
avatar文件 +bio描述），直接c.PostForm("bio")就行 - 如果先调了
c.FormFile("avatar")，再调c.PostForm("bio")依然有效 - 但若中间件或前置逻辑已读过
c.Request.Body，整个 multipart 解析都会失效，字段全为空
c.GetRawData()），后续所有基于 body 的解析（c.PostForm、c.ShouldBind、c.FormFile）都会静默失败。
