结构体字段必须导出且带正确json标签才能正确解析嵌套JSON；首字母小写字段会被json.Unmarshal静默忽略，导致零值；所有嵌套层级字段均需大写开头并严格匹配json键名大小写。
结构体字段必须导出且带正确 json 标签
嵌套 JSON 能否被正确解析，完全取决于 Go 结构体定义是否匹配。Iris 自身不做任何特殊处理，它只是把请求体交给 encoding/json。如果字段首字母小写（如 username string），json.Unmarshal 就无法访问，反序列化后值永远是零值。
常见错误：用 map[string]interface{} 接收嵌套数据，结果后续取 data["children"].([]interface{}) 时 panic —— 类型断言失败、无编译检查、校验和文档都丢失。
- 所有嵌套层级的字段都必须首字母大写（即导出）
-
json:"user_name"必须和请求字段名严格一致（区分大小写） - 数组字段用切片：
Children []TreeNode `json:"children"` - 可选嵌套对象用指针：
Meta *MetaInfo `json:"meta,omitempty"`
嵌套结构体要显式定义，不能靠 map 或 interface{} 临时凑
Iris 不会帮你“推断”树形关系。你传一个 {"name":"a","children":[{"name":"b"}]}，框架不会自动构造父子链表——它只按你给的结构体一层层递归填充。
示例中若定义了 type TreeNode struct { Name string `json:"name"` Children []TreeNode `json:"children"` }，就能完整接收无限深度嵌套；但若漏掉 Children 字段或类型写成 []interface{}，子节点就直接丢弃或 panic。
详细的 Three.js 3D 图形参考，涵盖场景设置、相机、几何体、材质、光照、动画、控制器、加载器、数学工具和调试。
- 避免用
json.RawMessage包裹整个嵌套块，除非你真要延迟解析 - 深层嵌套建议拆成独立结构体（如
type Node struct+type Tree struct），提升可读性和复用性 - 如果某层字段动态（如 key 是用户 ID），才考虑
map[string]Node，但需额外做键合法性校验
ReadJSON() 能自动处理嵌套，但未知字段默认静默忽略
ctx.ReadJSON(&v) 内部调用标准库 json.Unmarshal，对嵌套结构天然支持。但它不校验请求里是否存在未定义字段——比如结构体没声明 extra 字段，而客户端发了 {"name":"x","extra":"boom"}，Iris 默认照单全收，extra 被悄悄跳过。
这在调试时极难发现：前端多传了个字段，后端逻辑却因依赖该字段而错乱，日志里还看不到任何报错。
- 如需严格校验，加
json:"-"到结构体末尾并配合DisallowUnknownFields()（需自己 wrapjson.Decoder） - 更实用的做法是在结构体上加 validator tag，例如
Children []TreeNode `json:"children" validate:"dive"`，再用go-playground/validator主动校验 - 别依赖
ctx.ReadBody()+ 手动json.Unmarshal来绕过校验——那等于放弃 Iris 的 Content-Type 检查和缓冲复用优势
性能与调试：嵌套太深时注意栈溢出和循环引用
Go 的 json 包对嵌套层级没有硬限制，但实际使用中，超过 10 层嵌套容易触发 goroutine 栈溢出（尤其在低内存容器里）。另外，如果结构体不小心形成自引用（比如 A { B *B } + B { A *A }），ReadJSON 会无限递归直到 panic。
这类问题不会在编译时报错，只在运行时炸，且错误信息模糊（常是 runtime: goroutine stack exceeds 1000000000-byte limit）。
- 上线前用典型嵌套数据做压力测试，观察是否 panic 或响应变慢
- 结构体定义阶段就检查是否有意外的指针循环（IDE 通常能标出）
- 对超深嵌套场景，考虑分层接收：先
ReadJSON到顶层结构，再对RawMessage字段单独解析子树
