c.PostForm 是 Gin 中处理 POST 表单数据最常用且安全的方式，仅从请求体解析，自动适配 application/x-www-form-urlencoded 和 multipart/form-data，但要求 Content-Type 必须匹配，否则返回空。
c.PostForm 是最常用且安全的取值方式
直接用 c.PostForm("field") 获取表单字段，是 Gin 中处理 POST 表单数据的首选。它只从请求体（r.PostForm）中解析，不混入 URL 查询参数，也不依赖手动调用 ParseMultipartForm，对 application/x-www-form-urlencoded 和 multipart/form-data 都自动适配。
常见误操作包括：用 c.Query("field") 去读表单字段（查不到）、或在中间件里提前读了 c.Request.Body（导致后续 c.PostForm 返回空字符串）。
-
c.PostForm("username")没有该字段时返回""，适合做== ""判断 -
c.DefaultPostForm("username", "guest")可设默认值，省去判空逻辑 -
c.PostFormArray("hobby")用于多选 checkbox 或重复 name 的 input -
c.PostFormMap("user")对应前端 name="user[age]"、name="user[name]" 这类命名规则
Content-Type 不匹配会导致 c.PostForm 始终为空
这是最常被忽略的前提条件：c.PostForm 要求请求头 Content-Type 必须是 application/x-www-form-urlencoded 或 multipart/form-data。如果前端用 fetch 发送 JSON 但没改 header，或 Postman 里选了 “raw” + “JSON”，后端就收不到任何表单字段。
验证方法：打印 c.GetHeader("Content-Type")，确认是否为上述两种之一；不是的话，前端必须调整发送方式。
- HTML 表单默认就是
application/x-www-form-urlencoded，无需额外设置 - 使用
FormData构造请求时，浏览器会自动设为multipart/form-data，且不需手动写 header - 若用 axios 或 fetch 手动发表单，别设
Content-Type—— 让浏览器自动生成边界（boundary）
别把 c.ShouldBind 用错在普通表单上
c.ShouldBind 和 c.ShouldBindForm 看似更“高级”，但它们依赖结构体 tag 映射，容易因字段名不一致或 tag 写错（比如 form:"user_name" 但前端发的是 username）而静默失败，返回空值而非报错。
除非你明确需要结构体校验（如 binding:"required"），否则对简单表单，c.PostForm 更直接、更可控、更容易调试。
- 用
c.ShouldBindForm(&struct{})时，确保每个字段的formtag 和 HTML 的name完全一致 - 如果同时接收 JSON 和表单，不能共用一个结构体绑定 —— Gin 不支持混合解析，必须拆开：先
c.PostForm取表单，再c.ShouldBindJSON取 body（前提是 Content-Type 是 JSON） - 结构体字段首字母小写会导致绑定失败（Go 反射不可见），必须大写 + 合适的 tag
多个同名字段、嵌套字段怎么取
HTML 允许同名字段（如多选 checkbox）、或带方括号的嵌套命名（如 name="addr[city]"），Gin 提供了对应方法，但行为和直觉略有差异。
关键点在于：这些方法不依赖结构体，而是直接解析原始 form map，所以只要前端 name 写对，后端就能按规则提取。
-
c.PostFormArray("tag")返回[]string，适用于<input type="checkbox" name="tag" value="go">多个勾选 -
c.PostFormMap("profile")返回map[string]string，要求前端 name 是profile[name]、profile[email]格式 - 如果前端发的是
profile.name=xxx&profile.email=yyy（点号分隔），c.PostFormMap不识别，得用c.PostForm逐个取 - 数组型嵌套如
users[0][name]、users[1][email]，Gin 原生不支持自动转成 slice of struct，需手动解析
Content-Type 和请求体内容是否符合预期，比反复改后端逻辑更省时间。
