reflect.Value.Interface() panic 的根本原因是仅当值有效且可寻址（或非指针类型）时才可调用，nil 接口、nil 指针或未初始化字段会导致底层数据不可提取，应先校验 IsValid() 和 CanAddr()。
为什么 reflect.Value.Interface() 会 panic：nil pointer dereference
这是反射中最常见的崩溃点——对一个 nil 的 reflect.Value 调用 Interface()。它不报 “cannot interface with nil value”，而是直接 panic，容易误判为业务逻辑空指针。
根本原因是：只有可寻址（CanAddr()）且非 nil 的 reflect.Value 才能安全调用 Interface()；若原始值是 nil 接口、nil 指针或未初始化的 struct 字段，Value 对象本身可能有效，但其底层数据不可提取。
- 调试时先加断言：
if !v.IsValid() { log.Fatal("value is invalid") } - 再检查是否可转换：
if !v.CanInterface() { log.Printf("cannot Interface(): %v", v.Kind()) }（注意：CanInterface()并非标准方法，需手动判断IsValid() && CanAddr() || v.Kind() != reflect.Ptr等组合） - 更稳妥的做法是：只对明确知道非 nil 的指针类型做解引用，例如传入
&obj而非obj，并在反射前用if obj == nil拦截
struct 字段反射取值总返回零值？检查 Exported 和 CanInterface()
反射无法读取 unexported（小写开头）字段，也不会报错，而是静默返回该类型的零值（如 ""、0、nil）。这在调试时极难察觉，尤其当 struct 嵌套多层时。
同时，即使字段 exported，若原始变量不是指针或未寻址（比如直接传 struct 值而非 &s），reflect.Value.Field(i) 返回的仍是只读副本，修改无效，取值也可能因 copy 行为导致意外。
立即学习“go语言免费学习笔记（深入）”；
- 用
v := reflect.ValueOf(x); if !v.CanAddr() { ... }判断是否支持地址操作 - 打印字段名和是否 exported：
field := t.Field(i); fmt.Printf("%s: exported=%t, canSet=%t\n", field.Name, field.IsExported(), v.Field(i).CanSet()) - 想安全读写结构体字段，务必传指针：
reflect.ValueOf(&s).Elem()，否则Field()返回的是不可变副本
reflect.Call() 报错 call of reflect.Value.Call on zero Value
这个错误不是函数没找到，而是你传给 Call() 的 reflect.Value 根本不是 func 类型——它可能是 nil、struct 字段、或者从 Method() 获取时索引越界返回了零值 Value。
常见于动态调用方法时硬编码索引，或没校验方法是否存在。Go 不会在编译期报错，运行时才崩。
- 调用前必须双重确认：
if !fn.IsValid() || fn.Kind() != reflect.Func { panic("not a valid func") } - 查方法推荐用
v.MethodByName("Foo")而非v.Method(0)，并检查返回值：if !method.IsValid() { log.Fatal("method Foo not found") } - 参数要严格匹配签名：把每个参数包成
[]reflect.Value{reflect.ValueOf(arg1), reflect.ValueOf(arg2)}，不能漏、不能多、类型要一致（如*int不能传int）
反射性能突然变差？别在热路径反复做 reflect.TypeOf() 和 reflect.ValueOf()
这两个函数开销不小：每次调用都要分配内存、解析类型元信息、构建反射对象。如果在 for 循环或 HTTP handler 中高频使用，GC 压力和 CPU 占用会明显上升。
真正需要优化的不是“怎么写反射”，而是“能不能缓存反射结果”。类型信息是静态的，完全可以复用。
- 把
reflect.Type和常用reflect.Value（如 struct 的字段Field列表）存在包级变量或 sync.Map 中 - 用
unsafe.Pointer+ 类型断言替代部分反射场景（仅限已知结构且需极致性能时） - 用
go tool trace或pprof定位热点：若reflect.(*rtype).name或reflect.ValueOf占比高，基本就是缓存缺失
反射本身不是黑盒，但它放大了类型、生命周期和内存模型上的模糊地带。最常出问题的地方，往往不在反射调用那一行，而在上游传进来的那个接口值是不是 nil、那个 struct 是不是被复制过、那个方法名拼写有没有大小写错误——这些细节，debug 时得一层层往回扒。
