直接递归会栈溢出而非报错，因Go反射不检测循环引用，v.Elem()或v.Interface()遇自引用结构体时持续解引用直至栈满触发runtime panic；必须手动用UnsafeAddr()+Kind去重并严格校验IsValid、CanInterface和非空指针。
为什么直接递归会栈溢出而不是报错
Go 的 reflect.Value 本身不检测循环引用，v.Elem() 或 v.Interface() 遇到自引用结构体（比如 type Node struct { Next *Node }）时，只是不断解引用、取字段、再解引用……直到 goroutine 栈被撑爆，触发 runtime: goroutine stack exceeds 1000000000-byte limit。它不会提前告诉你“这里循环了”，因为反射层没义务做路径追踪。
用 uintptr 记录地址比 reflect.Value 更可靠
有人试过用 map[reflect.Value]bool 去重，结果失效——因为对同一底层对象多次调用 reflect.ValueOf() 会产生不同实例，reflect.Value 不能当 map 键用（不可比较），就算能，也不代表指向同一运行时对象。
- 必须先检查
v.CanAddr()，否则v.UnsafeAddr()会 panic - 只对
reflect.Ptr、reflect.Struct、reflect.Map、reflect.Slice这四类可能持引用的类型记录地址 - 键建议拼成
fmt.Sprintf("%p-%s", v.UnsafeAddr(), v.Kind())，避免不同 kind 的值地址冲突 - 切片底层数组、map 的 hmap、指针目标对象，都要进 map，不能只记结构体
遍历前必做的三道安检
漏掉任意一项，panic 就在下一行：
-
v.IsValid()—— nil interface{}、空指针的v.Field(i)会直接崩 -
v.CanInterface()—— 未导出字段（小写开头）调.Interface()必 panic -
v.Kind() == reflect.Ptr && !v.IsNil()—— 指针必须非空才能.Elem()，否则.Elem()panic
这三项不是可选步骤，是每次进入新字段前的硬性守门员。别指望“我这个结构体肯定没问题”——只要上游数据来自 JSON 解析、数据库扫描或用户输入，就一定有意外。
立即学习“go语言免费学习笔记（深入）”；
匿名字段和嵌套指针的双重陷阱
匿名字段（embedded field）容易让人误以为“自动展开”，其实反射里它仍是独立字段；而指针字段若没 .Elem() 就直接 .NumField()，会得到 0 并静默跳过，导致字段丢失。
- 遇到
f.Anonymous == true且v.Field(i).Kind() == reflect.Struct：跳过字段名，直接递归其内部字段，路径前缀不变 - 若匿名字段是
*Profile，得先v.Field(i).Elem()再判断 Kind，否则.Kind()是Ptr不是Struct - 路径拼接不能只靠
f.Name，要结合类型名或索引（如User.Profiles.0.Address.Street），否则同名嵌套字段会覆盖
真正麻烦的从来不是“怎么写”，而是“哪次忘了检查”。地址去重 + 三重校验 + 匿名/指针分治，缺一不可。上线后卡死比报错更难排查——因为没有堆栈，只有无限等待或突然崩溃。
