必须用 uintptr(unsafe.pointer(t)) 作 key，因 reflect.type 地址唯一稳定，而 string() 对匿名 struct 失效、pkgpath()+name() 在 vendoring 时易冲突；标准库如 encoding/json 采用此法，零开销且安全。
反射不是不能用，而是不能在热路径上裸用——缓存、索引、绕过，三者缺一不可。
缓存 reflect.Type 时为什么必须用 uintptr(unsafe.Pointer(t)) 做 key
同一类型的 reflect.Type 在整个程序生命周期内地址唯一且稳定，但它的 String() 或 PkgPath() + "." + Name() 都不可靠：前者对匿名 struct 返回空字符串，后者在 vendoring 或多模块版本共存时可能冲突。标准库（如 encoding/json）直接用 uintptr(unsafe.Pointer(t))，零开销、无分配、不依赖字符串逻辑。
- 别在
init()里预热所有类型——你根本不知道哪些会被用到 - 绝对不要缓存
reflect.Value：它每次调用都新建，不可比较、不能当 map key - 缓存内容建议是预计算好的结构体，比如
fieldInfo { Name string; Offset uintptr; Tag string; IsExported bool }，而不是裸的[]reflect.StructField
FieldByName 是 O(n) 查找，别让它出现在循环里
FieldByName 内部遍历所有字段做字符串比对，100 字段的 struct 就要比较 100 次；而 Field(i) 是数组下标访问，常数时间。高频场景下（如 ORM 映射、日志 dump），这个差异会直接拉低吞吐量。
- 提前构建
map[string]int字段名到索引的映射，后续查表即可 - 字段逻辑差异大（比如某些跳过、某些需解析 tag）时，缓存到字段级更灵活，key 可用
uintptr(unsafe.Pointer(&t)) + field.Name拼接 - 别用
sync.Map存这个映射：读多写少场景下，它的原子操作反而比普通map+sync.RWMutex慢
热路径彻底绕过反射：用 unsafe 生成零开销闭包
缓存只是“减损”，真正零反射开销的做法，是在初始化时用 unsafe.Offsetof 算出字段偏移，再封装成纯函数闭包。例如对 User.Name，预计算 offset := unsafe.Offsetof(User{}.Name)，再生成：
func(v interface{}) string {
return *(*string)(unsafe.Pointer(uintptr(unsafe.Pointer(&v)) + offset))
}
这种手法在 msgpack、gogoprotobuf 中广泛使用，实测比缓存反射快 5–10 倍，GC 分配趋近于零。
- 必须确保输入是可寻址的（通常传指针）
- 字段类型必须稳定：若结构体加字段或改顺序，需重新生成
- 不能用于嵌套字段或接口字段——偏移计算只对一级导出字段有效
反射前必做的三重检查：IsValid → CanInterface → 类型断言
FieldByName 找不到字段时返回零值，不是 nil，直接调用 Interface() 会 panic。必须按顺序检查：
- 先调
val.IsValid()：否则后续方法全可能 panic - 再调
val.CanInterface()：这是Interface()的前置条件；如果只是取底层值，优先用String()、Int()等专用方法 - 最后做类型断言：
val.Interface().(string)，避免泛型擦除后运行时错误 - 对
map或slice元素做反射时，记得先MapIndex()/Index()，再检查有效性
真正难的不是写出反射代码，而是判断某处是否值得用反射——多数时候，硬编码字段访问、预生成序列化器、甚至代码生成（go:generate），比 runtime 反射更稳更快。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
