为什么 Go 语言中 nil interface != nil？深度理解底层结构

先抛个结论：`interface{}` 变量和 `nil` 比较，判断依据不是它存的值是不是空，而是底层那两个隐藏字段——类型指针 `_type` 和数据指针 `data`——是否**同时为零**。只有全 16 字节都是 0，这个接口才真正算 `nil`。

### interface{} == nil 的判断逻辑不是“值为空” 很多人一上来就踩坑：把一个 `*int` 类型的 `nil` 指针赋给 `interface{}`，结果接口变量 `!= nil`；或者函数返回 `error` 类型，内部明明返回了 `(*MyError)(nil)`，调用方用 `if err != nil` 判断却根本没进分支，最后 panic。问题出在哪儿？赋值时，`_type` 字段被填成了 `*MyError` 的类型信息地址（非零），而 `data` 确实是 `nil` —— 一个非零一个零，整体自然不等于 `nil`。 ### eface 结构体暴露了“nil 不等于 nil”的真相 `interface{}` 对应的运行时结构叫 `eface`，定义在 `runtime/iface.go` 里： ```go type eface struct { _type *_type data unsafe.Pointer } ``` 汇编层面，`== nil` 的判断就是对着这 16 字节做一次内存比较（x86-64 下通常是两条 `MOVQ` + 一次 `ORQ` 或 `TESTQ`）。只要 `_type` 非零，哪怕 `data` 是 `nil`，整个结构体就不等于 `nil`。 看两个典型场景： - `var p *int = nil; var i interface{} = p` → `i._type != nil`，所以 `i != nil` - `var i interface{} = nil` → `i._type == nil && i.data == nil`，所以 `i == nil` ### 如何安全判断 interface{} 是否“逻辑上为空” 不能只依赖 `== nil`，特别是当变量来自函数返回值或者类型断言之后。推荐组合使用反射和类型检查： - 对任意 `interface{}`，用 `reflect.ValueOf(x).Kind() == reflect.Ptr && reflect.ValueOf(x).IsNil()` 判断底层指针是否为空 - 如果已知具体类型（比如 `error`），优先用类型断言后判空：`if e, ok := err.(someError); ok && e == nil` - 更稳妥的做法是：**避免让 `nil` 指针流入接口**。函数返回 `error` 时，直接返回 `nil`，而不是 `(*MyError)(nil)` 示例函数： ```go 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: return rv.IsNil() } return false } ``` ### error 类型为什么通常不踩这个坑 标准库里的 `error` 虽然是接口类型，但绝大多数实现（包括 `errors.New`、`fmt.Errorf`）返回的是**值类型实例的指针**，而且函数签名明确返回 `error` 接口。当你写 `var err error = nil` 时，编译器生成的就是纯粹的 `eface{nil, nil}`；而如果某个函数内部返回 `(*MyErr)(nil)`，那就破坏了这一约定。 关键点在于：接口变量的“nil 性”完全取决于它**怎么被赋值**，而不是它“看起来像不像空”。同一个 `*T` 类型，直接赋给 `interface{}` 和先转成 `T` 再赋，底层 `_type` 字段可能指向不同的运行时类型元数据。 最容易忽略的是跨包传递：别人导出的函数如果返回了带类型的 `nil` 接口值，光看签名根本看不出是否安全——要么翻源码或文档，要么统一用反射兜底。