Go反射无递归深度限制，需手动设防：用depth参数校验、地址+类型标识去重、切片模拟栈替代递归，三者缺一不可，否则循环引用导致栈溢出且recover无效。
Go 反射本身不设递归深度限制，但不加防护的递归遍历结构体、切片或 map 会直接栈溢出 panic，且 recover 无效——这不是反射的缺陷，是你没主动设防。
为什么 reflect.Value.Interface() 一递归就崩溃
当结构体字段包含自身指针（如 *Node）或通过 map/slice 形成引用环时，reflect.Value.Interface() 或 .Elem() 在内部会无限展开，直到 runtime 强制终止 goroutine。错误信息通常是：runtime: goroutine stack exceeds 1000000000-byte limit。
- 这不是 JSON 或其他库报的错，是反射底层调用链自己崩的
-
recover()捕不到，因为这不是 Go 的 panic，而是操作系统级栈耗尽 - 哪怕只调一次
v.Interface()，只要 v 内部含循环引用，就可能触发
必须手动维护已访问对象标识
不能靠地址比较（unsafe.Pointer），因为相同内存地址可能对应多个 reflect.Value 实例；也不能只记 v.UnsafeAddr()，因为非可寻址值（如 struct 字面量、interface{} 中的值）返回 0。
- 只对
reflect.Ptr、reflect.Map、reflect.Slice、reflect.Struct这四类类型记录访问状态 - 键格式建议：
fmt.Sprintf("%p-%s", v.UnsafeAddr(), v.Kind())，但前提是v.CanAddr() == true - 遇到重复键立即返回（比如返回
false或自定义错误），不再向下递归该分支
递归入口必须带 depth 参数并校验
Go 不做任何隐式深度控制，所有反射遍历函数都得自己管。不设限 = 用户数据决定你程序是否存活。
立即学习“go语言免费学习笔记（深入）”；
- 入口第一行写：
if depth > maxDepth { return errors.New("recursion too deep") } -
maxDepth不宜硬编码为 100；常见场景参考值：JSON 解析 ≤ 20，YAML include ≤ 8，AST 遍历 ≤ 50 - 每次递归调用传
depth + 1，初始调用从 0 开始 - 避免用
len(slice)做终止条件——它不反映当前递归层级，容易漏判
更稳的做法：用切片模拟栈代替递归
对用户可控性差的场景（比如解析第三方传入的嵌套结构），迭代比递归可靠得多。栈深可随时检查，逻辑也更容易中断或限流。
- 把待处理节点存进
[]reflect.Value，每次 pop 一个处理 - 子节点用
append(stack, child)入栈，不调函数 - 循环内加
if len(stack) > maxDepth { return err }，比参数传递更直观 - filepath.WalkDir、json.RawMessage 解析等标准库实现，本质都是这种思路
真正难的不是写递归，而是判断「哪里该停」——地址去重、深度计数、类型守门，三者缺一不可。少一个，遇到恶意嵌套数据就是线上 panic。
