reflect.ValueOf在循环中必触发GC且FieldByName线性查找致p99延迟升1–2ms；须预缓存Type和字段索引，用FieldByIndex替代，key用uintptr(unsafe.Pointer(t))，Set前必检CanSet()，interface{}反射得底层类型，nil需IsValid()防护。
reflect.ValueOf 在循环里直接调用必出错
不是“可能慢”，而是每次都会分配约 96 字节的 reflect.Value 实例，触发 GC；更致命的是，FieldByName 是线性遍历字段名做字符串比对——100 字段就要比 100 次。高频循环中这会直接让 p99 延迟跳升 1–2ms。
常见错误写法：for _, item := range items { v := reflect.ValueOf(item); v.FieldByName("ID").Int() }
- 必须把
reflect.TypeOf和字段索引预计算好，缓存到结构体或 map 中 - 用
FieldByIndex替代FieldByName，查表是 O(1) - 别在
init()里预热所有类型——你根本不知道哪些会被用到
缓存 key 用 uintptr(unsafe.Pointer(t)) 而不是 t.String()
reflect.Type 地址在整个程序生命周期内稳定唯一，可安全作 key；而 t.String() 对匿名 struct 无效，t.PkgPath() + "." + t.Name() 在 vendoring 或多模块共存时可能冲突。
错误示例：cache[t.String()] = fieldMap
立即学习“go语言免费学习笔记（深入）”；
- 正确做法：
key := uintptr(unsafe.Pointer(t))，零开销、无拼接、不依赖路径 - 别用
sync.Map存字段映射——读多写少场景下，原子操作反而比普通map+sync.RWMutex慢 - 缓存内容建议是结构体（如
type fieldInfo { Name string; Offset uintptr; Tag string }），不是裸的[]reflect.StructField
CanSet() 不只是安全检查，漏判会导致 panic 难定位
对非指针值调用 reflect.ValueOf(x) 得到的是副本，CanSet() 返回 false；只有传入指针并调用 Elem() 才能真正修改原值。但更关键的是：漏掉 CanSet() 就直接 SetInt()，运行时 panic 信息是 reflect: reflect.Value.SetInt using unaddressable value——不提示行号，只报包名，排查成本极高。
- 必须在
SetXxx前加if !v.CanSet() { ... }判断 - 对
interface{}值做反射时，reflect.TypeOf返回的是底层实际类型（如*MyStruct），不是interface{}——这不是类型丢失，是预期行为 - 传入
nil时，reflect.ValueOf(nil)返回零值，后续调用.Kind()或.Type()会 panic，应先用.IsValid()
unsafe.Offsetof 闭包快但危险，只适合明确瓶颈点
对稳定结构体（如 DB 模型），预计算字段偏移并封装成纯函数闭包，实测比缓存反射快 5–10 倍，GC 分配趋近于零。但它不是通用方案，而是手术刀式优化。
典型错误：offset := unsafe.Offsetof(User{}.Name) 后，把闭包用于接口类型变量，或未确保 User 不被 GC。
- 闭包必须接收指针（如
func(u *User) string），且字段顺序/类型不能变 - 启用
//go:build !no_unsafe时，整个逻辑会失效 - 真正难的不是学会怎么用
reflect，而是判断“这里到底该不该用”——很多本可用类型断言或泛型解决的地方，硬套反射只会把问题埋得更深
