gin 不支持一次 shouldbind 多个结构体，需用嵌套结构体+form/ json 标签+dive 实现多源参数合并校验，或封装 bindmerged 函数分步绑定并统一处理错误。
ShouldBind 无法自动合并两个结构体？别硬拼
直接在 c.ShouldBind() 中传入两个结构体变量是无效的——Gin 不支持一次绑定到多个结构体。所谓“合并校验”，本质是把多个来源的参数映射到一个统一结构体中，或分层校验后组合判断。
常见错误现象：写 var a A; var b B; c.ShouldBind(&a); c.ShouldBind(&b)，结果第二个绑定覆盖了第一个的上下文，或因 Content-Type 不匹配（比如 JSON 请求里用 ShouldBindQuery()）导致字段全空却无报错。
- 必须明确参数来源：是 JSON body、URL query、form 表单、path 参数，还是 header？不同来源要用对应绑定方法
- 结构体字段标签必须与实际传入字段名一致，且带对应 binding 标签（
json:/form:/uri:等），否则字段不赋值 →binding:"required"形同虚设 - 若需同时处理 body 和 query（如分页 + 数据体），应定义一个顶层结构体，内嵌子结构，并用
dive处理嵌套校验
用嵌套结构体 + dive 实现多层校验
当请求同时含 JSON body 和 URL query（例如 POST /user?page=1，body 含用户数据），推荐定义一个顶层结构体，将 query 和 body 字段分别内嵌，并用 dive 触发子结构体的 binding 校验。
示例：
type PageQuery struct {
Page int `form:"page" binding:"required,gte=1"`
}
type UserBody struct {
Name string `json:"name" binding:"required,min=2"`
Email string `json:"email" binding:"required,email"`
}
type CreateUserRequest struct {
PageQuery `form:""` // 注意空 form 标签，表示从 query 绑定
UserBody `json:""` // 空 json 标签，表示从 body 绑定
}
然后统一调用：
var req CreateUserRequest
if err := c.ShouldBind(&req); err != nil {
// err 是 validator.ValidationErrors 类型，可断言遍历
}
-
form:""和json:""是关键：它们让 Gin 分别从 query 和 body 提取字段，而不是只看结构体名 - 必须加
dive才能校验内嵌结构体字段，但 Gin 默认不自动加；需显式写成PageQuery `form:"" binding:"dive"` - 如果漏掉
dive，外层结构体校验通过，但内嵌字段的binding规则完全不触发
ShouldBindJSON + ShouldBindQuery 拆开调用的坑
有人会拆成两步：c.ShouldBindJSON(&body) + c.ShouldBindQuery(&query)。这可行，但极易出错。
- 若请求是
application/json但 query 为空，ShouldBindQuery仍会成功返回 nil（不是 error），导致query.Page为 0 —— 而你本意是“page 必填” - 若前端误发
Content-Type: application/x-www-form-urlencoded却调用ShouldBindJSON，直接 panic 报invalid character错误 - 两次绑定共用同一个 context，第二次可能读不到原始 body（已被第一次解析消耗），尤其在 multipart 场景下更明显
- 错误处理分散：两个 err 需手动合并，而
validator.ValidationErrors无法跨结构体聚合，字段名容易重复（如两个结构体都有ID）
自定义 Bind 方法封装统一入口
最可控的方式是封装一个 BindMerged 函数，内部按顺序尝试不同绑定方式，并统一收集 ValidationErrors。
核心逻辑：
func BindMerged(c *gin.Context, body interface{}, query interface{}) error {
// 先 bind query
if err := c.ShouldBindQuery(query); err != nil {
return err
}
// 再 bind body（根据 Content-Type 自动选）
if err := c.ShouldBind(body); err != nil {
return err
}
return nil
}
但注意：这个函数只是顺序执行，不解决字段冲突和错误聚合。真要合并提示，得自己断言 err 类型：
- 用
errors.As(err, &validationErrors)判断是否为 validator 错误 - 遍历
validationErrors，用error.Field()和error.StructNamespace()区分来源（如"PageQuery.Page"vs"UserBody.Name"） - 中文提示需提前注册
zh翻译器，否则err.Translate(trans)返回英文
真正麻烦的从来不是怎么写校验规则，而是当 query、body、header、path 四处都有参数时，字段命名冲突、标签遗漏、绑定顺序依赖、错误信息无法定位到具体来源——这些细节一旦漏掉一个，调试成本就翻倍。
