高频反射调用导致吞吐量下降3–5倍、gc翻倍，必须缓存reflect.type（用uintptr(unsafe.pointer(t))作key）并预计算字段索引，热路径禁用fieldbyname和value.call，改用偏移访问和闭包优化。
高频反射调用不是“慢一点”的问题，而是直接让吞吐量掉 3–5 倍、GC 分配翻倍的硬伤。缓存 reflect.Type 和预计算字段索引是必须做的底线，但真正省事又安全的做法，是根本不在热路径上碰 reflect.ValueOf 和 FieldByName。
缓存 reflect.Type 时别用 interface{} 或 string 当 key
同一类型的 reflect.Type 在整个程序中地址恒定，但 Go 不允许它直接作 map key（不可比较）。常见错误是写成 typeCache[reflect.TypeOf(x)] = info —— 编译就报错；或者退而求其次用 t.String()，结果匿名 struct 返回空字符串，vendoring 下包路径变化还会导致 key 冲突。
- 正确 key：用
uintptr(unsafe.Pointer(t))，零开销、稳定、标准库（如encoding/json）也在用 - 错误 key：
map[interface{}]T（接口含值指针，不同变量即使类型相同也无法命中）、map[string]T（字符串分配+哈希开销大，且对匿名类型失效） - 不用
sync.Map：纯读多写少场景下，它的原子操作比普通map+sync.Once初始化更慢
字段访问必须绕过 FieldByName
FieldByName 是线性遍历，100 字段的 struct 平均要比对 50 次，每次还触发内存分配。它不 panic、不报错，只默默返回零值——拼错字段名或大小写不对（比如传 "name" 但字段叫 "Name"），就会静默失败。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 首次查一次：用
t.FieldByName("Name")得到索引i，存进包级 map，key 同上用uintptr(unsafe.Pointer(t)) - 后续全走
v.Field(i)：常数时间访问，无字符串比对、无分配 - 缓存内容建议是结构体
fieldInfo { Name string; Offset uintptr; Tag string; IsExported bool }，不是裸的[]reflect.StructField
热路径上彻底不用 reflect.Value.Call
reflect.Value.Call 单次开销 100–500ns，瓶颈不在“调用”本身，而在每次调用前的 receiver 可寻址性校验和参数逐个转换。哪怕你缓存了 reflect.Method，只要没绕过 Call，这些开销就还在。
- 正确做法：用
unsafe.Offsetof算出字段偏移，封装成闭包，例如func(v interface{}) string { return *(*string)(unsafe.Pointer(uintptr(unsafe.Pointer(&v)) + offset)) } - 方法调用可预计算入口地址（Go 1.14+
internal/abi布局稳定），再用unsafe构造函数指针，运行时只剩指针传递 - 前提很关键：输入必须可寻址（通常传指针），且字段/方法签名和内存布局绝对稳定；结构体加字段、改顺序就得重新生成，否则 runtime crash
最容易被忽略的不是“怎么缓存”，而是“哪些类型值得缓存”——别在 init() 里预热所有类型，你根本不知道哪些会被用到；缓存应懒加载、按需构造。真正的性能拐点，往往卡在第一次 reflect.TypeOf 被调用的位置，而不是第 10000 次。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
