反射调用方法时 panic: value call of nil 的原因
这是最常遇到的反射 panic，本质是 reflect.Value 为空（nil），却直接调用了 Call 或 Method。比如对 nil 指针或未初始化结构体字段做反射调用。
常见错误现象：panic: reflect: call of reflect.Value.Call on zero Value 或更隐蔽的 panic: value call of nil。
- 检查前必须确认
v.Kind() == reflect.Ptr且v.IsNil() == false，再用v.Elem()获取实际值 - 若目标是结构体方法，确保该方法接收者不是指针而你传入的是值类型——此时
v.MethodByName()返回零值reflect.Value - 用
v.CanInterface()判断是否可安全转回原类型；不可时别硬转，否则可能 panic
// 错误：v 是 nil 指针的 reflect.Value
v := reflect.ValueOf((*MyStruct)(nil))
v.MethodByName("Do").Call(nil) // panic！
// 正确：先判空再解引用
if v.Kind() == reflect.Ptr && !v.IsNil() {
v = v.Elem()
}
if v.IsValid() && v.Kind() == reflect.Struct {
method := v.MethodByName("Do")
if method.IsValid() {
method.Call(nil)
}
}
反射访问字段时 panic: reflect: Field index out of range
字段索引越界通常发生在用 Field(i) 硬编码下标，但结构体字段顺序/数量变了，或者没考虑匿名嵌入字段带来的偏移。
使用场景：动态读写结构体字段，比如 ORM 映射、配置绑定。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 永远优先用
FieldByName("Name")而非Field(0)，避免依赖字段顺序 - 若必须用索引（如遍历所有导出字段），先通过
t.NumField()校验范围，再循环i - 注意
FieldByName对大小写敏感，且只找导出字段（首字母大写）；私有字段需用FieldByNameFunc+CanSet()配合判断
反射转换失败 panic: reflect: Call using ... as type ...
这个 panic 出现在用 reflect.Value.Call 传参时，参数类型和函数签名不匹配。Go 反射不会自动类型转换，哪怕 int 和 int64 看似兼容也不行。
性能影响明显：每次 reflect.ValueOf(x) 都有分配开销，错误类型还会导致 panic 后恢复成本更高。
- 调用前逐个检查参数
reflect.Value的Type()是否与目标函数参数类型完全一致（包括包路径） - 用
reflect.TypeOf(fn).In(i)拿到第 i 个参数期望类型，再比对arg.Type() - 整数类型尤其危险：
int、int64、uint之间不能混用；字符串和[]byte也不能互转
// 错误：传 int 但函数要 int64
fn := func(x int64) {}
reflect.ValueOf(fn).Call([]reflect.Value{reflect.ValueOf(42)}) // panic！
// 正确：显式转成目标类型
reflect.ValueOf(fn).Call([]reflect.Value{reflect.ValueOf(int64(42))})
recover 反射 panic 不够用？别只靠 defer
单纯在反射调用外加 defer/recover 很容易漏掉深层 panic，比如方法内部又触发了另一次反射操作并 panic，而外层 recover 已退出作用域。
容易被忽略的地方：反射代码往往嵌套在中间件、钩子或泛型封装里，panic 发生位置离 recover 点很远。
- 每个独立的反射操作边界都应有自己的
defer/recover，而不是只在外围包一层 - recover 后别只打印日志就完事，要返回明确错误（如
fmt.Errorf("reflect call failed: %v", r)），让上层能区分业务错误和反射崩溃 - 注意 recover 只捕获当前 goroutine 的 panic；跨 goroutine 的反射 panic 无法被捕获，需避免在 goroutine 中裸跑反射逻辑
反射本身不难，难的是它把编译期能发现的类型错误全拖到运行时。每多一层间接，就多一分失控风险。写的时候多花十秒加 IsValid() 和 CanInterface() 判断，比上线后查三天 panic 日志划算得多。
