FieldByName比Field(i)慢十几倍，因其每次调用都线性遍历所有字段并逐个字符串比对，20字段struct平均需10次比较；而Field(i)是数组下标访问，O(1)常数时间，实测慢约17倍。
FieldByName 为什么比 Field(i) 慢十几倍
因为 FieldByName 是线性字符串匹配：每次调用都遍历所有字段，逐个比对 string 名称。20 字段的 struct 平均查 10 次才命中；而 Field(i) 是数组下标访问，常数时间。
实测显示，相同赋值逻辑下，FieldByName 比 Field(0) 慢约 17 倍（来自 2023 年基准测试）。这不是小数点后优化，是数量级差异。
- 字段名稳定时，启动时预建
map[string]int映射，后续查表 O(1) - 别用
sync.Map存这个映射：读多写少场景下，普通map+sync.RWMutex更快 - key 用字段名即可，无需拼包路径；value 存索引，不是
reflect.StructField
缓存 reflect.Type 有用，但缓存 reflect.Value 是陷阱
reflect.Type 是只读元数据指针，整个进程内地址唯一，缓存安全有效；reflect.Value 是运行时快照，每次 reflect.ValueOf(x) 都会新分配、重新包装、触发接口转换——它根本不能复用。
常见错误是把 reflect.Value 塞进全局 map 或结构体字段里，这不仅白缓存，还可能阻止 GC、引发并发读写 panic。
立即学习“go语言免费学习笔记（深入）”；
- 推荐 cache key：用
uintptr(unsafe.Pointer(t))，零开销、不依赖字符串、不惧 vendoring - 避免用
t.String()或t.PkgPath() + "." + t.Name()，匿名 struct 会失效，多版本模块易冲突 - 缓存内容建议是轻量结构体，比如
type fieldInfo { Offset uintptr; Tag string; IsExported bool }
CanSet() == false？大概率没传指针
想用反射改 struct 字段却 panic：reflect: cannot set，90% 是因为传了值而非地址。Go 要求可设置必须同时满足：值可寻址（addressable），且字段导出（首字母大写）。
小写字母字段（如 name string）永远不可通过反射修改，v.FieldByName("name").CanSet() 必为 false，这不是 bug，是语言设计。
- 错误写法：
reflect.ValueOf(myStruct).FieldByName("Name").SetString("x") - 正确写法：
reflect.ValueOf(&myStruct).Elem().FieldByName("Name").SetString("x") - 注意：
Elem()后才是可寻址副本；若myStruct是函数返回的临时值，取地址也可能因逃逸不足而失败
热路径彻底绕过反射：用 unsafe.Offsetof 生成闭包
缓存只是“减损”，真正零反射开销的做法，是在初始化时算出字段偏移，封装成纯函数闭包。运行时只做指针偏移和类型转换，无分配、无查表、无接口转换。
例如对 User.Name 字段，预计算 offset := unsafe.Offsetof(User{}.Name)，再构造：func(v interface{}) string { return *(*string)(unsafe.Pointer(uintptr(unsafe.Pointer(&v)) + offset)) }
- 实测比缓存反射快 5–10 倍，GC 分配趋近于零
- 前提：输入必须是可寻址的（通常传指针），且字段布局稳定（增删字段或改顺序会导致 silent fail）
- 更适合序列化库、ORM 等构建期已知类型的场景；调试 dump 或插件系统这类动态类型仍需反射，但应严格限频、采样或仅 debug 开启
最易被忽略的是：字段偏移计算依赖 struct 布局稳定性，而 layout 可能被编译器重排（尤其含 go:build tag 或不同 GOOS/GOARCH 下），这种失效不会报错，只会静默读错字段。
