interface{}为nil需类型和数据指针均为nil；仅数据指针为nil时接口非nil，故==nil判断失效；应使用reflect.ValueOf(v).IsNil()或带ok的类型断言判空。
为什么 interface{} 为 nil 时，直接判 == nil 有时不生效
Go 接口变量是两字宽结构：一个指向类型信息的指针 + 一个指向数据的指针。只有当这两者**都为零值**（即类型字段为 nil 且数据字段为 nil）时，接口才真正为 nil。但常见错误是：把一个非空类型的指针（比如 *MyStruct）赋给接口后，即使该指针本身是 nil，接口变量也不为 nil——因为类型字段已填充。
- 典型错误现象：
var p *bytes.Buffer; var i interface{} = p; fmt.Println(i == nil) // 输出 false - 根本原因：接口已绑定
*bytes.Buffer类型，只是底层数据指针为nil - 这导致很多“空指针防护”逻辑失效，比如在 JSON 解析或 RPC 返回中误判结构体是否初始化
判断接口内具体值是否为 nil 的安全做法
不能只看接口变量本身，得拆开检查其动态值。最稳妥的方式是用 reflect.ValueOf 提取底层值再判断：
func IsNil(v interface{}) bool {
if v == nil {
return true
}
rv := reflect.ValueOf(v)
switch rv.Kind() {
case reflect.Chan, reflect.Func, reflect.Map, reflect.Ptr, reflect.Slice, reflect.UnsafePointer:
return rv.IsNil()
default:
return false
}
}
- 仅对可空类型（
Ptr、Slice等）调用IsNil()，其他类型如int或string永远返回false - 注意：传入未导出字段或不可寻址值时，
reflect.ValueOf可能 panic，建议先用rv.IsValid()防御 - 性能敏感场景慎用反射；若只处理固定几种类型，可手动展开判断（比如专用于
*T就直接类型断言）
类型断言后判 nil 的常见误写与修正
很多人想当然地写 v.(*MyType) == nil，但这会 panic——类型断言失败时返回零值和 false，不是 nil。
- 错误写法：
if v.(*MyType) == nil { ... }→ 断言失败直接 panic - 正确写法（带 ok 判断）：
if p, ok := v.(*MyType); ok && p == nil { ... } - 更推荐统一走
IsNil()工具函数，避免重复写ok分支 - 如果确定接口只可能装某一种指针类型，且允许 panic（如测试代码），可用
*(v.(*MyType))强制解引用再判空，但生产环境不建议
JSON 解析后接口字段为 nil 的实际表现
用 json.Unmarshal 解析到 interface{} 字段时，null 值会被转成 nil 接口，但嵌套结构里字段为 null 后再赋值给接口，容易混淆。
立即学习“go语言免费学习笔记（深入）”；
- 示例：
json.Unmarshal([]byte(`{"data":null}`), &m); fmt.Println(m["data"] == nil) // true - 但如果
m["data"]是*struct{}类型，且 JSON 是{"data":{}}，那它不为nil，只是字段为空 - 关键区别：JSON 的
null→ Go 的nil接口；而空对象{}→ 非nil的结构体实例 - 别依赖
== nil判断业务上的“空”，应结合字段语义做明确校验（比如检查len(slice)或field != ""）
接口的 nil 判断本质是类型系统与运行时表示的交界问题，最容易被忽略的是：你以为在检查值，其实是在检查接口头；而真正的“空”往往藏在类型内部。
