用 reflect.Value 遍历时怎么避免栈溢出
Go 的反射本身不阻止循环引用，reflect.Value 递归调用 Interface() 或 Elem() 时，一旦结构体字段指向自身或形成环，就会直接 panic：「runtime: goroutine stack exceeds 1000000000-byte limit」。这不是反射的 bug，而是你没设访问边界。
实操上必须自己维护已访问对象的标识。不能只比对指针地址（unsafe.Pointer），因为相同地址可能来自不同 reflect.Value 实例；推荐用 reflect.Value 自身的 UnsafeAddr() + 类型组合做唯一键：
- 对
reflect.Ptr、reflect.Map、reflect.Slice、reflect.Struct这四类可能持引用的类型才记录 - 键格式建议：
fmt.Sprintf("%p-%s", v.UnsafeAddr(), v.Kind())（注意：仅限非零地址，v.CanAddr()必须为 true） - 遇到重复键立即停止该分支遍历，返回标记（比如
bool或自定义错误）
json.Marshal 报错 json: invalid recursive type 怎么定位源头
这个错误不是反射层抛的，是 encoding/json 包在构建内部类型缓存时检测到循环嵌套（比如 struct A 含 *A 字段）。它不告诉你哪一行，只报类型名。
快速定位方法：把疑似类型单独传给 json.Marshal 测试，配合 go vet -tags=json（虽不完美但能捕获部分明显循环）；更稳的是用反射预检：
立即学习“go语言免费学习笔记（深入）”；
- 写个轻量函数，用
reflect.TypeOf从根类型出发，逐字段检查是否出现「当前类型 → 当前类型」的直接引用链 - 重点盯
reflect.Struct的字段和reflect.Ptr的Elem()，跳过接口、函数、chan 等不可序列化类型 - 别依赖
String()输出判断，要用reflect.Type.Name()和reflect.Type.PkgPath()共同确认是否同一类型
为什么用 map[uintptr]bool 记录访问地址会漏判
uintptr 只保存地址数值，但 Go 中相同逻辑对象在不同 reflect.Value 实例里，UnsafeAddr() 可能返回不同值——尤其是对 interface{} 底层数据、map/slice 元素、或经 reflect.Indirect() 处理后的值。
常见误判场景：
- 一个 struct 字段是
interface{}，里面装了 *T，此时v.Field(i).UnsafeAddr()是 interface header 地址，不是 *T 的实际地址 - 遍历 map 时，
reflect.Value.MapKeys()返回的 key/value 是副本，UnsafeAddr()无效（返回 0） - 对 slice 元素调用
v.Index(i)后，若未确认v.CanAddr()，UnsafeAddr()会 panic 或返回 0
正确做法：只对 v.CanAddr() == true 且 v.Kind() 属于可寻址类型的值，才用 v.UnsafeAddr() 构建键。
深度遍历中要不要考虑 interface{} 的动态类型循环
要。interface{} 是最隐蔽的循环入口。比如 var x interface{} = &x，反射时 v.Kind() == reflect.Interface，但 v.Elem().Kind() 才是真实类型，且可能又是指向自己的指针。
处理原则：
- 遇到
reflect.Interface，先用v.Elem()解包，再判断是否可寻址、是否需加入已访问集合 - 解包后若仍是
reflect.Interface（嵌套 interface），最多展开 1 层，避免无限递归解包 - 如果
v.IsNil()为 true，跳过后续检查，不记录地址（nil 接口没有底层地址）
真正难缠的是跨包类型别名 + interface{} 组合，这时 PkgPath() 和 Name() 都可能不同，得靠 reflect.Type.String() 做粗筛，再结合地址判断实例关系。
