Go反射调用无法提速，只能绕开或固化开销路径：缓存reflect.Type、用Method(i)替代MethodByName、用FieldByIndex+Offset实现零拷贝访问、高频场景绕过reflect.Value.Call，且需配合结构体稳定性检查。
Go反射调用本身无法“提速”，只能绕开或固化它的开销路径。真正有效的做法不是优化 reflect.Value.Call，而是让大部分调用不经过它。
缓存 reflect.Type 和 reflect.Method，别碰 reflect.Value
每次调用 reflect.TypeOf 或 reflect.ValueOf 都会触发类型系统遍历和结构体分配；reflect.Value 是值绑定的，不可复用，缓存它等于白干。
-
reflect.Type是只读全局单例，同一类型多次调用reflect.TypeOf返回的指针地址恒定，可安全缓存 - 用
t.Method(i)替代v.MethodByName("Save")：前者返回常量结构体，后者每次线性扫描方法表 - key 用
uintptr(unsafe.Pointer(t))，别用interface{}或t.String()—— 前者哈希开销大，后者分配字符串 - 字段访问同理：缓存
t.FieldByName("Name").Index，后续走v.FieldByIndex(indexes)，跳过字符串匹配
用 FieldByIndex + Offset 实现零拷贝字段访问
当结构体布局稳定（无字段增删、无影响对齐的 tag 变更），字段偏移在初始化阶段算一次，运行时直接指针运算，速度接近原生访问。
- 初始化时：
f, _ := reflect.TypeOf(User{}).FieldByName("Name"); nameOffset = f.Offset - 运行时：
*(*string)(unsafe.Pointer(uintptr(unsafe.Pointer(u)) + nameOffset)) - 必须加
//go:build !race条件编译，否则 race detector 报错 - 该方式不适用于栈上未逃逸对象（GC 可能移动内存），生产环境建议用
go run -gcflags="-l" -race测试兼容性
高频调用场景直接绕过 reflect.Value.Call
reflect.Value.Call 的瓶颈不在“调用”动作，而在每次调用前的 receiver 可寻址性校验、参数类型转换和返回值打包。热路径上应彻底规避。
- Go 1.14+ 可预计算方法入口地址：
funcPtr := *(*uintptr)(unsafe.Pointer(uintptr(unsafe.Pointer(t)) + offsetToMethodTable + i*8)) - 封装为闭包函数，接收
interface{}后做一次类型断言或 unsafe 转换，再调用 - 签名必须严格匹配，否则 runtime crash —— 这是绕过反射的代价：失去类型安全校验
- 若方法签名可能变更，宁可缓存
reflect.Method并调用.Func.Call()，也不硬编码偏移
最容易被忽略的点是：字段顺序或 tag 变更会让所有基于 Offset 和 Index 的缓存瞬间失效，且毫无提示。这类优化必须配合 CI 中的结构体稳定性检查，或用代码生成工具自动生成访问器，而不是靠人肉维护。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
