c.PostForm 是获取 POST 表单参数最直接安全的方式，仅从 r.PostForm 解析，不混入 URL 参数，自动处理 multipart，返回空字符串而非 panic，并支持默认值；失败主因是 Content-Type 错误、结构体 tag 不匹配或 body 被提前读取。
c.PostForm 是获取 POST 表单参数最直接、最安全的方式，前提是请求头 Content-Type 为 application/x-www-form-urlencoded 或 multipart/form-data。别用 c.Query 或 c.Param 去碰表单字段，它们根本读不到 body 里的数据。
为什么 c.PostForm 比 r.FormValue 更适合 Gin 场景
虽然原生 http.Request 的 r.FormValue("key") 也能取到表单值，但在 Gin 中它会混入 URL 查询参数（?q=abc），导致逻辑错乱；而 c.PostForm("key") 只从 POST body 解析出的 r.PostForm 里取，干净且意图明确。
- 显式区分来源：POST 表单 vs URL 查询参数，避免意外覆盖
- 自动处理
ParseMultipartForm：对multipart/form-data（含文件上传）也生效，不用手动调ParseMultipartForm - 返回空字符串而非 panic：没该字段时返回
""，方便做== ""判断 - 配合
c.DefaultPostForm("key", "default")可设默认值，省去 if 判空
c.PostForm 无法取到值的三个高频原因
不是函数写错了，而是请求本身不满足前提条件。常见现象是始终返回空字符串，但日志看不出报错。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 前端没发对 Content-Type：比如用 fetch 发 JSON 却没改 header，或 Postman 里选了 “raw” 而非 “form-data” / “x-www-form-urlencoded”
- 用了
c.ShouldBind但结构体 tag 写错：比如Name string `json:"name" form:"username"`，c.ShouldBindForm就会去找username字段，但表单实际发的是name→ 值永远为空 - body 已被提前读取：比如在中间件里调了
c.GetRawData()或c.Request.Body，后续c.PostForm就失效（HTTP body 只能读一次）
接收混合参数：表单 + URL 查询 + JSON body 怎么办
真实接口常同时要 query 参数（如 ?page=2）、表单字段（如 username=admin）和 JSON payload（如 {"extra":{}}）。Gin 不支持单次绑定混合类型，必须拆开处理。
立即学习“go语言免费学习笔记（深入）”；
- 先用
c.ShouldBindQuery(&queryStruct)绑定查询参数 - 再用
c.ShouldBindForm(&formStruct)绑定表单字段（注意结构体 tag 全部用form:） - 最后用
c.ShouldBindJSON(&jsonStruct)绑定 JSON body（tag 全部用json:） - 不要混用：
c.ShouldBind会根据Content-Type自动选解析器，但一旦发错类型（比如表单发了 JSON），它就静默失败，且不报错
最容易被忽略的是：表单字段名和结构体 tag 必须严格一致，且 c.PostForm 和 c.ShouldBindForm 对大小写、下划线、连字符都敏感——前端传 user_name，结构体就得写 User_name string `form:"user_name"`，少一个下划线就拿不到值。
