高频反射慢在重复校验、类型转换和线性搜索，单次Call耗100–500ns；应避免模板中反复调用方法，改用预计算字段或FuncMap纯函数，用Field(i)替代FieldByName，缓存reflect.Method而非reflect.Value，极致场景可用unsafe绕过反射。
高频反射不是慢在“调用”，而是每次都要重复校验 receiver 可寻址性、逐个转换参数类型、线性搜索方法表或字段名——这些开销加起来，单次 reflect.Value.Call 就要 100–500ns；10 万次就是 10–50ms，足够拖垮一个 HTTP handler。
避免在模板中反复调用方法
Go 模板引擎对 {{.User.GetName}} 这类写法，每次渲染都走一遍反射调用，且无法缓存。若在 {{range .Users}} 中调用，性能随用户数线性恶化。
- 把方法结果提前算好：传入
UserName string字段，而非整个User结构体 - 必须保留方法逻辑时，注册为
template.FuncMap中的纯函数（如"get_user_name": func(u *User) string { return u.Name }），绕过模板层反射分发 - 禁用
template.HTML或自定义Stringer实现作为模板输入，它们会触发额外的接口检查和方法查找
用字段偏移替代 FieldByName
FieldByName 是线性遍历，100 字段就要比 100 次字符串；而 Field(i) 是数组下标访问，常数时间。真正瓶颈不在“读字段”，而在“找字段名”。
- 初始化时一次性计算：
nameOffset := unsafe.Offsetof(User{}.Name) - 封装为闭包：
func(u *User) string { return *(*string)(unsafe.Pointer(uintptr(unsafe.Pointer(u)) + nameOffset)) } - 确保结构体字段导出、无
//go:notinheap标记，且字段顺序不变更（否则 offset 失效） - 别在
init()里预热所有可能用到的结构体——按需构造，否则白占内存
缓存 reflect.Method，而不是 reflect.Value
reflect.Value 每次调用都新建，不可比较、不能当 map key，缓存它毫无意义；而 reflect.Method 是只读全局单例，地址恒定，可安全复用。
立即学习“go语言免费学习笔记（深入）”；
- 正确缓存 key：
uintptr(unsafe.Pointer(reflect.TypeOf(&v).Elem()))，不是reflect.TypeOf(v).String()（匿名 struct 会失效） - 缓存值应是
reflect.Method，不是reflect.Value.Method(i).Call()的结果（后者绑定具体实例，无复用价值） - 调用前仍需
reflect.ValueOf(&v)构造 receiver，但至少省掉了MethodByName的哈希+遍历开销 - 若热路径要求极致性能，Go 1.14+ 可用
unsafe直接算方法表偏移并构造函数指针——但签名错一点就 crash，调试成本高
最容易被忽略的是：哪怕你缓存了 reflect.Method，只要还走 reflect.Value.Call，receiver 校验和参数类型转换这两步就逃不掉。真要零开销，就得彻底离开反射路径，用 unsafe 生成闭包——代价是放弃类型安全和结构体布局灵活性。
