reflect.Value.IsNil() 不能直接用于普通指针变量，必须先经 reflect.ValueOf() 包装且确保值有效、可寻址、Kind 为六种支持类型之一（Ptr/Map/Slice/Chan/Func/Interface），否则 panic；其性能比 p == nil 慢约100倍，且不适用于 interface{} 底层值判空，日常应优先使用直接比较。
reflect.Value.IsNil() 不能直接用于普通指针变量
你不能对一个 *string 变量直接调用 reflect.Value.IsNil()——这会编译失败或 panic。必须先用 reflect.ValueOf() 包装，且该值必须是可寻址、可反射的。常见错误写法：reflect.ValueOf(p).IsNil()，其中 p 是未取地址的局部指针变量，此时返回的 reflect.Value 不可寻址，IsNil() 会 panic：“call of reflect.Value.IsNil on zero Value”。
正确做法是传入指针的地址（即双重指针）或确保原值来自可寻址上下文（如结构体字段、切片元素）：
-
reflect.ValueOf(&p).Elem().IsNil()—— 适用于局部变量p *string -
reflect.ValueOf(u.Profile).IsNil()—— 适用于结构体导出字段Profile *Profile，前提是u本身可寻址（如&u传入）
直接比较 p == nil 比反射快两个数量级
在基准测试中，if p == nil 的耗时稳定在 0.25 ns/op 左右；而等效的反射写法 reflect.ValueOf(&p).Elem().IsNil() 约为 25–30 ns/op，慢约 100 倍。这不是因为 IsNil() 本身慢，而是反射构造 reflect.Value 的开销主导了成本：分配元信息、检查可寻址性、类型擦除与还原。
这个差距在高频路径（如 HTTP 中间件、gRPC 拦截器、日志字段提取）里会累积成可观延迟。尤其当嵌套判断多层（如 req.User.Profile.Address）时，每层都用反射，性能雪崩风险真实存在。
立即学习“go语言免费学习笔记（深入）”；
接口类型判空时，reflect.Value.IsNil() 容易误用
对 interface{} 变量调用 reflect.ValueOf(v).IsNil() 是无效的——它只判断该接口变量自身是否为 nil（即 type 和 value 都为空），但无法告诉你底层具体值是否为 nil 指针。例如：
var p *bytes.Buffer = nil; var w io.Writer = p，此时 w 不为 nil，但 reflect.ValueOf(w).IsNil() 返回 false，这和你想检查的“底层 *bytes.Buffer 是否为空”完全不是一回事。
真要查接口底层指针是否为 nil，必须先类型断言再判空：if bw, ok := w.(*bytes.Buffer); ok && bw == nil。用反射绕路不仅更慢，还容易写出逻辑错误的判断。
别为了“统一抽象”把 == nil 替换成反射
有些工具函数试图封装“任意类型判空”，结果内部全走 reflect.Value.IsNil()。这看似灵活，实则埋雷：
- 对非支持类型（如
int、string）调用会 panic - 对 struct 值、数组等类型，
IsNil()直接报错：“invalid operation: cannot call IsNil on struct Value” - 零值语义混淆：比如
time.Time{}是合法零值，但不是 nil，也不该被当成“空”处理
Go 的 nil 是类型专属概念，硬塞进反射泛型抽象里，既失语义又损性能。真正需要动态类型的场景（如 ORM 字段扫描），应限定输入为指针/接口/map/slice，并提前校验 Kind，而不是无差别喂给 IsNil()。
最常被忽略的一点：反射判空从来不是“更安全”的替代方案，它只是另一套机制，适用面窄、开销高、错误信号弱。日常开发中，p == nil 就是唯一该用的方式——简单、快、编译期可验证、panic 位置明确。
