直接调用 reflect.value.numfield() 会 panic，因未检查 val.isvalid() 就访问字段；需先验证有效性、处理指针解引用、跳过未导出字段，并对匿名字段和循环引用做特殊防护。
直接用 reflect.Value 递归遍历带循环引用的结构体，必 panic，不是 bug，是你没设访问边界。
为什么 reflect.Value.NumField() 一调就崩溃
因为嵌套结构体里常混着 nil 指针、interface{}、未导出字段（小写开头），甚至循环引用链。比如 val.Field(i) 遇到 nil *T 字段，不加判断就继续 .Elem()，立刻触发 panic: reflect: call of reflect.Value.Elem on zero Value；对未导出字段调 .Interface() 同样 panic。
- 每次取字段前必须先检查
val.IsValid()，否则.Kind()或.NumField()都可能崩 - 只对
val.CanInterface() == true的字段做类型转换，跳过所有小写字段 - 对
reflect.Ptr类型，先判val.IsNil()再决定是否.Elem() - 对
reflect.Struct，需递归处理匿名字段（val.FieldByIndex([]int{i})），但得防重复进入同一地址
如何用反射安全检测循环引用而不漏判
不能只比对 unsafe.Pointer，因为相同逻辑对象在不同 reflect.Value 实例中，UnsafeAddr() 可能返回不同值——尤其是 interface{} 底层数据、map/slice 元素、或经 reflect.Indirect() 处理后的值。
- 只对
reflect.Ptr、reflect.Map、reflect.Slice、reflect.Struct这四类可能持引用的类型记录访问标识 - 键格式建议：
fmt.Sprintf("%p-%s", v.UnsafeAddr(), v.Kind())，但前提是v.CanAddr() == true且v.UnsafeAddr() != 0 - 遇到重复键立即停止该分支遍历，返回
false或自定义错误（如ErrCycleDetected） - 别依赖
v.String()判断类型，要用v.Type().Name()和v.Type().PkgPath()共同确认是否同一类型
为什么 json.Marshal 报 json: invalid recursive type 却不告诉你哪一行
这个错误不是反射层抛的，是 encoding/json 在构建内部类型缓存时检测到循环嵌套（比如 struct A 含 *A 字段），它只报类型名，不报字段路径。
- 快速定位：把疑似类型单独传给
json.Marshal测试，配合go vet -tags=json（虽不完美但能捕获部分明显循环） - 更稳的是用反射预检：写个轻量函数，从
reflect.TypeOf(root)出发，逐字段检查是否出现「当前类型 → 当前类型」的直接引用链 - 重点盯
reflect.Struct的字段和reflect.Ptr的Elem()，跳过interface{}、func、chan等不可序列化类型
真正难的不是写检测逻辑，而是区分哪些循环是设计所需（如树节点的 parent 字段）、哪些是意外强引用（如全局 map[interface{}]*T 持有本不该长期存活的对象）。后者才可能拖慢 GC，前者只要不参与 GC 根扫描，其实无害。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
