reflect.Value.Call 开销大（80–120 ns）且易 panic，主因是 receiver 不可寻址；应缓存 reflect.Method/Type，热路径用 MakeFunc 生成闭包绕过反射调用。
reflect.Value.Call 是反射调用里最重的一环，单次开销稳定在 80–120 ns；直接调用同方法仅约 1.2 ns。高频场景下不优化，吞吐量会断崖式下跌。
为什么 reflect.Value.Call 一调就 panic
最常见原因是传入了不可寻址的 receiver：reflect.ValueOf(v).MethodByName("Foo").Call() 中 v 是值类型（比如 struct{}），reflect.Value 就不是 addressable，立刻 panic “call of reflect.Value.Call on zero Value”。
- 必须确保 receiver 是指针：
reflect.ValueOf(&v)，而非reflect.ValueOf(v) - 调用前加两道保险：
if !method.IsValid() || !method.CanCall() { ... } - 方法名小写（如
doSomething）或接收者类型不匹配（传MyStruct{}却要调指针接收者方法）也会导致method为零值
缓存什么才真正有效：别碰 reflect.Value，盯紧 reflect.Method 和 reflect.Type
reflect.Value 每次调用都新建，不可比较、不能当 map key，缓存它等于白干；而 reflect.Method 和 reflect.Type 是只读、全局单例，地址恒定，可安全复用。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 正确缓存 key：
uintptr(unsafe.Pointer(t))，其中t = reflect.TypeOf(&v).Elem()；避免用t.String()（匿名 struct 失效）或包路径拼接（vendoring 下冲突） - 缓存内容建议是结构体：
struct{ method reflect.Value; in, out []reflect.Type }，方便后续参数校验预检 - 别缓存
reflect.Value.Method(i).Call()的结果——它依赖具体实例，毫无复用价值
热路径彻底绕过 Call：用 reflect.MakeFunc 或 unsafe 生成闭包
缓存 MethodByName 只省掉约 15–20% 开销（字符串查找部分），真正瓶颈在 Call 本身。热路径上应生成纯函数闭包，运行时零反射开销。
立即学习“go语言免费学习笔记（深入）”；
- 固定签名场景（如所有 handler 都是
func(ctx context.Context) error）：用reflect.MakeFunc在初始化阶段生成闭包，后续调用等价于普通函数 - 字段访问类高频操作：预计算
unsafe.Offsetof(User{}.Name)，再封装为func(v interface{}) string { return *(*string)(unsafe.Pointer(uintptr(unsafe.Pointer(&v)) + offset)) } - 注意：
unsafe方式绕过了类型系统校验，必须确保结构体布局稳定（不加/删/重排字段）、方法签名绝对匹配，否则 runtime crash
最容易被忽略的点是：性能瓶颈不在“调用”动作本身，而在每次 Call 前对 receiver 可寻址性校验和参数类型逐个转换——哪怕你缓存了 reflect.Method，只要没绕过 Call，这部分开销就还在。
