Gin 默认不支持多层嵌套结构体自动绑定，必须使用预定义带正确json标签的结构体配合ShouldBind才能可靠解析并校验；map[string]interface{}或interface{}接收会导致校验失效、类型丢失和panic风险。
直接说结论：Gin 默认不支持多层嵌套结构体的自动绑定（比如 map[string]interface{} 或深层嵌套 JSON），但可以通过 ShouldBind + 正确标签 + 预定义结构体实现可靠解析；强行用 interface{} 或 map[string]interface{} 接收再手动递归解包，容易漏字段、丢类型、难校验。
嵌套 JSON 绑定必须用结构体，不能靠 map[string]interface{}
很多人尝试用 var data map[string]interface{} 接收 POST 的嵌套 JSON，结果发现 c.ShouldBind(&data) 虽然不报错，但子字段无法被 validator 校验，且 int/float 类型可能变成 float64（JSON 解析默认行为），后续做类型断言极易 panic。
- ✅ 正确做法：为每层嵌套定义明确结构体，用
json:标签对齐字段名 - ⚠️ 常见错误：只定义顶层结构体，子对象用
map[string]interface{}，导致binding:"required"失效 - ? 注意：Gin 的 validator 不递归校验
map或interface{}里的字段，只校验结构体一级字段
c.ShouldBind 能自动识别嵌套，但依赖 Content-Type 和标签
c.ShouldBind 会根据请求头 Content-Type 自动选绑定器（application/json → JSON 绑定器，application/x-www-form-urlencoded → form 绑定器），但前提是结构体字段标签写对：
- JSON 请求必须用
json:"field_name"，不是form:或uri: - 嵌套字段标签要完整，例如：
User User `json:"user" binding:"required"`，其中User类型本身也要有json:标签 - 如果前端传的是
{"user":{"name":"a","age":25}}，而结构体里写成User User `json:"user_info"`，字段就为空
数组+嵌套结构体：注意 slice 字段的 binding 标签位置
当请求体含数组（如 "items": [{"id":1,"meta":{"k":"v"}}]），结构体定义和校验容易出错：
Colly 是一个用于 Go 语言的快速开源爬取和爬虫框架。它适用于从简单的页面提取到异步爬虫处理大量页面集合，支持请求回调和结构化解析。
立即学习“go语言免费学习笔记（深入）”；
- slice 字段本身不加
binding:"required"—— validator 不校验 slice 是否为空，只校验其元素 - 想要求至少一个元素，得写
Items []Item `json:"items" binding:"min=1"` - 嵌套在 slice 元素里的结构体，其字段仍需独立加
binding:，例如Meta MetaInfo `json:"meta" binding:"required"` - 若用
c.ShouldBindJSON替代c.ShouldBind，效果一样，但失去自动 Content-Type 判断能力，不推荐
深层嵌套 + 可选字段：用指针避免零值覆盖
当某层嵌套字段可选（比如 "address" 整个对象可能不存在），又希望区分“没传”和“传了 null”，必须用指针：
- ❌
Address Address `json:"address"`：没传时Address是零值（空 struct），无法判断是否客户端省略 - ✅
Address *Address `json:"address"`：没传时为nil，可明确判断 - validator 对指针字段的
required检查是判非 nil，不是判内部字段，这点常被忽略 - 如果字段既可空又需校验内部，得手动判
if req.Address != nil { validate(req.Address) }
真正麻烦的不是嵌套本身，而是混合场景：URL 参数 + JSON Body + Header 同时存在，且部分字段跨层级共享。这时候别硬塞进一个结构体，拆成多个绑定目标更可控——c.ShouldBindQuery、c.ShouldBindJSON、c.ShouldBindHeader 分开调，反而不容易丢逻辑分支。
