ShouldBindQuery不支持嵌套结构体自动展开，仅解析扁平键名；需手动展平字段并用form标签对齐，如user_name；ShouldBindJSON才原生支持嵌套解析。
ShouldBindQuery 不支持嵌套结构体自动展开
直接用 ShouldBindQuery 绑定带嵌套字段的结构体，URL 参数会全部丢失——Gin 的 query 解析器只处理扁平键名，不识别点号（user.name）或方括号（user[name]）这类嵌套语法。哪怕结构体定义了 form 标签，只要字段是嵌套类型（比如 User User），ShouldBindQuery(&v) 就不会把 ?user.name=foo&user.age=25 映射进去，所有嵌套字段保持零值。
嵌套参数必须手动展平并用 form 标签对齐
想让 URL 查询参数支持“类嵌套”语义，唯一可行方式是：把嵌套结构体拆成顶层字段，并在 form 标签里显式写出带前缀的 key 名。Gin 只认这个字符串，不解析结构关系。
-
form:"user_name"对应?user_name=alice，不是?user.name=alice -
form:"profile_age"对应?profile_age=30，而非?profile[age]=30 - 如果原始结构体是
type Req struct { User struct{ Name string } }，必须重写为Name string `form:"user_name"` - 多个嵌套层级建议控制在 1 层以内，否则 URL 难读、前端难拼、调试难定位
ShouldBindJSON 才真正支持嵌套结构体
如果你的请求体是 JSON（Content-Type: application/json），ShouldBindJSON 能原生解析嵌套对象、数组、指针字段，且无需额外配置。这是 Gin 唯一开箱即用支持嵌套的绑定路径。
- 结构体用
json标签，如Name string `json:"name"`，嵌套字段同理 - 前端发
{"user":{"name":"bob","age":28}}，后端结构体可定义User struct{ Name string `json:"name"`; Age int `json:"age"` } - 注意：
ShouldBind（无后缀）在 JSON 请求中会退化为ShouldBindJSON，但行为不如显式调用稳定，尤其在混合 Content-Type 场景下 - 别指望
ShouldBind同时兼容 JSON 和 query —— 它按 Content-Type 分流，query 参数永远进不去
真要传嵌套查询参数？自己解析 + 映射
极少数场景（比如兼容旧前端、第三方系统强制要求 ?filter[status]=active&filter[topic]=go），你得放弃 ShouldBindQuery，改用手动解析。
- 用
c.Request.URL.Query()拿到url.Values - 遍历 key，用字符串前缀（如
"filter["）识别嵌套组，再用strings.TrimSuffix提取字段名 - 对每个匹配项，用
strconv.Atoi/strconv.ParseBool等转类型，再赋值给结构体字段 - 这种逻辑无法复用，每次都要写，且容易漏边界（空值、重复 key、非法格式）
嵌套查询参数本质违背 REST 和 HTTP 设计原则，Gin 不支持是故意的。能走 JSON 就别硬套 query，这是最常被忽略的底层约束。
