反射调用前必须先检查接收者Value是否有效且非nil：需依次验证IsValid()、Kind()类型及IsNil()，尤其接口类型要解包Elem()后递归判断，禁用Interface()==nil等不可靠方式。
反射调用前必须先检查接收者 Value 是否有效且非 nil
Go 反射调用方法（reflect.Value.Call()）时，如果接收者是 nil 指针，会直接 panic：「call of method on nil pointer」。这不是运行时错误，而是反射层的硬性限制——reflect.Value.Call() 要求接收者必须可寻址或至少非 nil（对指针类型而言）。但注意：reflect.ValueOf(nil) 得到的是 Invalid 值，.Call() 会先 panic；而 reflect.ValueOf(&s).Elem() 得到结构体值，此时即使原始指针是 nil，也早已在 Elem() 阶段 panic 了。
所以真正要判断的，是「你传给 reflect.ValueOf() 的那个接收者变量本身是否为 nil」，且它必须是支持 Call() 的类型（即指针、接口、或实现了方法的非指针值）。
- 若接收者是
*T类型：先v.IsValid()，再v.Kind() == reflect.Ptr，最后v.IsNil()—— 三者缺一不可 - 若接收者是接口（如
io.Writer）：不能只看v.IsNil()，因为接口为 nil 仅当其类型和值均为 nil；更常见的是接口非 nil 但底层具体值为 nil（比如var w io.Writer = (*bytes.Buffer)(nil)），此时v.IsNil()返回false，但后续调用w.Write()仍会 panic - 若接收者是值类型（
T）：v.IsNil()必 panic，因为reflect.Ptr才支持IsNil()；值类型永远不为 nil，可直接调用，无需判空
接口类型接收者需额外解包并递归判断底层值
当你拿到一个 reflect.Value，其 Kind() 是 reflect.Interface，且你要用它做方法调用（比如该接口有 Close() 方法），那么仅靠 v.IsNil() 不足以保证安全：它只告诉你这个接口变量本身是否为 nil（即类型+值都 nil），但无法告诉你它内部装的 *os.File 或 *bytes.Buffer 是否为 nil。
正确做法是先确认它是接口，再取 v.Elem()，然后对 v.Elem() 做标准 nil 判断（IsValid() → Kind() → IsNil()）。
立即学习“go语言免费学习笔记（深入）”；
-
v.Kind() != reflect.Interface→ 不走此分支 -
!v.IsValid()→ 已无效，视为 nil -
v.IsNil()→ 接口本身为 nil，安全返回 true - 否则调
v.Elem()，再对其结果重复 nil 判断逻辑（注意：若v.Elem().Kind()是reflect.Ptr，才可继续IsNil()）
不要依赖 v.Interface() == nil 判接收者
v.Interface() 返回的是 interface{}，而 Go 中 interface{} 和 nil 比较有陷阱：只要它内部存了类型信息（哪怕值是 nil），v.Interface() == nil 就是 false。例如：
var p *int = nil v := reflect.ValueOf(p) fmt.Println(v.Interface() == nil) // false！
这导致你以为接收者“不为空”，结果一调 .Call() 就 panic。更糟的是，这种写法在泛型或 interface{} 参数场景下完全不可靠。
- 永远不用
v.Interface() == nil做反射前判断 - 永远不用
== nil直接比较reflect.Value，它不是可比类型 - 所有判断必须基于
v.IsValid()、v.Kind()、v.IsNil()三步组合
封装一个安全的接收者检查函数
实际项目中建议封装一个统一入口，覆盖指针、接口、及接口内嵌指针的场景。下面这个函数能避免绝大多数 panic：
func canCallOn(v reflect.Value) bool {
if !v.IsValid() {
return false
}
switch v.Kind() {
case reflect.Ptr:
return !v.IsNil()
case reflect.Interface:
if v.IsNil() {
return false
}
elem := v.Elem()
if !elem.IsValid() {
return false
}
switch elem.Kind() {
case reflect.Ptr:
return !elem.IsNil()
default:
return true // 值类型或 map/slice 等，可调用（只要方法存在）
}
default:
return true // 值类型直接可 Call
}
}
这个函数不保证方法一定存在，只确保调用不会因接收者 nil 而 panic。它没处理 reflect.Map 或 reflect.Slice 作为接收者的情况（它们不能有方法），但已覆盖绝大多数真实场景。最易忽略的是：接口内嵌指针后，v.Elem().Kind() 可能还是 reflect.Interface（比如嵌套两层接口），这时需要递归——但实践中极少出现，过度递归反而引入复杂度和性能损耗。
