ShouldBind按Content-Type自动选解析器，易因header错误静默失败；应优先用ShouldBindJSON/Query/Form显式绑定，并统一结构体tag。
表单数据取不到？检查 Bind 和 ShouldBind 的区别
Gin 里最常踩的坑是：表单提交了，c.PostForm("xxx") 能取到值，但用 c.ShouldBind(&struct{}) 却报错或字段为空。根本原因是绑定逻辑不同：ShouldBind 默认按 Content-Type 自动选择解析器（application/json 走 JSON 解析，application/x-www-form-urlencoded 或 multipart/form-data 才走表单解析），而 PostForm 强制从表单中读。
- 如果前端用
fetch+FormData提交，后端必须用c.ShouldBind(&v)或c.Bind(&v)，且结构体字段要加form:"xxx"标签（如Name string `form:"name"`） -
Bind遇错直接 400 并终止执行；ShouldBind返回 error，可自行判断处理 - 若混用 JSON 和表单（比如 Swagger 测试用 JSON 提交但生产走表单），建议统一用
c.ShouldBindWith(&v, binding.Form)显式指定解析器
验证失败没提示？别只依赖 binding 标签
Gin 内置的 binding:"required" 只做基础校验，且错误信息固定为英文、无法定制，线上出问题时前端根本不知道哪错了。
- 验证失败时
c.Error(err)不会自动返回响应，必须手动调用c.AbortWithStatusJSON(400, gin.H{"error": err.Error()}) -
required对空字符串、零值（如0、false）都判为无效，但表单里数字输入框提交空值会被转成0，导致“必填”失效——这时得用指针类型（如*int）配合required_if或自定义校验 - 更稳妥的做法是用
go-playground/validator/v10替代原生 binding，支持中文错误提示、跨字段校验（如密码重复）、正则等，初始化时注册翻译器即可
文件和文本字段一起提交？注意 multipart/form-data 的边界
带文件上传的表单，Gin 默认把整个请求体当 multipart 解析，但如果你先调用了 c.PostForm("xxx")，再调用 c.FormFile("file")，后者大概率返回 nil, err —— 因为 PostForm 已触发一次解析，body 流被消耗掉了。
- 必须把所有字段读取操作放在
c.FormFile之前，或统一用c.MultipartForm()一次性获取全部表单值和文件 - 文件字段名和结构体字段名不一致时，
form:"avatar"标签只影响文本字段，文件要用c.FormFile("avatar")显式指定 key - 大文件上传需提前设置
gin.SetMode(gin.ReleaseMode)和router.MaxMultipartMemory = 8 << 20（8MB），否则默认 32MB 可能吃光内存
中文字段名验证失败？结构体标签里的 form 和 json 别写反
前端传的是 用户名: "张三" 这种中文 key，后端结构体却写了 Username string `json:"用户名" form:"username"`，结果 ShouldBind 总是跳过这个字段——因为表单解析只认 form 标签，json 标签在此场景下完全无效。
- 表单提交时，
form:"xxx"的xxx必须和 HTML<input name="xxx">或 FormData 的 key 完全一致（包括大小写、下划线、中文） - 不要为了兼容 JSON 接口而在同一个 struct 上混用
json和form标签，容易冲突；建议分两个结构体，或用 map[string]string 先接原始表单再手动赋值 - 如果前端用 axios 且未设置
Content-Type，它可能默认发application/json，此时 Gin 会尝试 JSON 解析而非表单解析，导致所有form标签失效
