json.marshal报“invalid recursive type”因encoding/json检测到循环嵌套类型（如type a struct { next *a }），仅报类型名不显字段路径；需结合reflect.type.name()与pkgpath()精准定位，辅以预检函数、栈防护及字段索引缓存优化。
为什么json.Marshal报“invalid recursive type”却不告诉你哪一行
这个错误不是反射层抛的，是encoding/json在构建内部类型缓存时检测到循环嵌套（比如type A struct { Next *A }），它只报类型名，不暴露字段路径。直接打印reflect.TypeOf(x).String()没用——相同名字可能来自不同包，得用reflect.Type.Name()和reflect.Type.PkgPath()联合判断。
快速定位方法：
- 把疑似结构体单独传给
json.Marshal测试，缩小范围 - 用
go vet -tags=json扫描，能捕获部分明显循环（如自引用字段未加json:"-"） - 写轻量预检函数：从根
reflect.Type出发，对每个reflect.Struct字段和reflect.Ptr的Elem()递归检查是否出现「当前类型 → 当前类型」的直接引用链
用reflect.Value遍历结构体时panic: “runtime: goroutine stack exceeds 1000000000-byte limit”
这不是bug，是你没设访问边界。Go反射本身不阻止循环引用，reflect.Value.Interface()或Elem()一旦遇到环，就会无限递归直到栈溢出。
必须自己维护已访问对象标识，但不能只比对unsafe.Pointer：
-
uintptr只保存地址数值，同一逻辑对象在不同reflect.Value实例里，UnsafeAddr()可能返回不同值（尤其interface{}底层、slice元素、reflect.Indirect()后） - 正确做法：仅对
reflect.Ptr、reflect.Map、reflect.Slice、reflect.Struct这四类才记录；键格式用fmt.Sprintf("%p-%s", v.UnsafeAddr(), v.Kind())，且必须先确认v.CanAddr() == true - 遇到重复键立即停止该分支遍历，返回
false或自定义错误，别硬扛
FieldByName + 循环引用 = 双重性能灾难
FieldByName本就是性能黑洞：线性遍历+字符串比较，20字段struct平均查10次才命中；若字段又指向自身，每次FieldByName都触发一次完整递归校验，CPU和栈开销指数级放大。
绕过方案要同时解决两个问题：
- 字段访问：启动时用
reflect.Type.NumField()+reflect.Type.Field(i)预建字段名→索引映射，后续直接v.Field(idx)，跳过名称查找 - 循环防护：预扫描阶段就记录所有可寻址字段的
UnsafeAddr()组合键，后续遍历时查表O(1)判重，不等走到Interface()再崩 - 字段带
json:"user_id"这类tag？解析也必须在初始化阶段完成，不要每次反序列化都重来
缓存reflect.Type比缓存reflect.Value安全得多
很多人想缓存reflect.Value省掉reflect.ValueOf(x)调用，这是危险操作——reflect.Value绑定了具体数据实例，无法跨变量复用，还可能因GC提前失效。真正该缓存的是只读元数据：
-
reflect.Type和reflect.StructField数组：全局单例，可安全存sync.Map[reflect.Type][]int（字段偏移路径） - 避免缓存整个
reflect.StructField，用[]int更轻量（如[1, 0]表示Outer.Inner.ID），利于GC - 对同一类型，
reflect.TypeOf(&x).Elem()只调一次，结果存局部变量或包级变量，别放循环里
最易被忽略的一点：即使你写了完整的循环防护和字段索引缓存，只要在HTTP handler里对每个请求都新建reflect.Value并调Interface()，性能瓶颈就还在——反射的堆分配和逃逸分析失效，是硬伤。真要高频处理，要么切到go:generate生成专用函数，要么接受代价，严格限制调用频次和输入规模。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
