在 Go 开发里，nil != nil 是一个很典型、也很容易误判的问题：明明具体指针已经是 nil，放进接口后再判断，却得到 false。要把这个现象看明白，关键不是背结论，而是理解接口在运行时到底保存了什么，以及这种设计为什么会影响 error、方法调用和日常判空。
下面就从接口的内部结构讲起，再结合一个可复现的示例，拆开说明为什么“值是 nil”不等于“接口本身是 nil”，最后再看工程里最常见的踩坑点和更稳妥的写法。
接口为什么会出现“看起来是 nil，比较却不是 nil”
Go 语言里的接口变量，底层并不是一个单独的“空值标记”，而是由两部分组成：
// $GOROOT/src/runtime/runtime2.go
type iface struct {
tab *itab // 类型信息指针
data unsafe.Pointer // 实际数据指针
}可以把它理解成两项运行时信息：
tab：保存具体类型信息以及方法集data：指向接口里实际承载的数据
这就决定了，接口是否等于 nil，判断的不是“它里面的值像不像 nil”，而是这两个字段是否同时为空：
tab == nil && data == nil只有类型信息和数据指针都为 nil，这个接口值本身才是 nil。只要其中一个不为空，接口就不是 nil。
一个最典型的复现场景
这个问题最容易出现在“具体类型的 nil 指针赋值给接口”时。先看例子：
package main
import (
"fmt"
)
type Person struct {
Name string
Age int
}
func (p *Person) String() string {
if p == nil {
return "<nil Person>"
}
return fmt.Sprintf("Name: %s, Age: %d", p.Name, p.Age)
}
func main() {
var p *Person = nil // 具体类型的 nil 指针
var i interface{} //
fmt.Println(p == nil) // output: true
fmt.Println(i == nil) // output: true
// 赋值给接口
i = p
fmt.Println(p == nil) // output: true
fmt.Println(i == nil) // output: false, p 为 nil，而 i 不为 nil
}
前半段很好理解：p 是空指针，i 还没放任何值，所以二者都等于 nil。
真正的变化发生在 i = p 之后。虽然 p 依然是 nil，但接口 i 已经拿到了“它装的是 *Person 类型”这条信息，于是接口内部会变成：
tab => 包含 *Person 类型信息 (非nil)
data => nil这时候 data 虽然还是 nil，但 tab 已经不是 nil，因此整个接口值不再等于 nil。
如果想直接观察接口当前携带的类型和值，可以用反射：
fmt.Println(reflect.TypeOf(i), reflect.ValueOf(i))
// output: *main.Person <nil>这个输出很能说明问题：接口里确实保存着 *main.Person 这个具体类型，只是它当前对应的值是 <nil>。
为什么 Go 要保留这份类型信息
很多人第一次看到这个行为，会觉得 Go 在“故意挖坑”。但从接口设计本身看，这其实是为了保证运行时行为一致。
接口不仅要装值，还要支持方法动态派发。也就是说，即便接口里承载的是一个 nil 指针，只要它的具体类型明确，Go 仍然知道该调用哪个方法。
还是看这个例子：
package main
import (
"fmt"
)
type Person struct {
Name string
Age int
}
func (p *Person) String() string {
if p == nil {
return "<nil Person>"
}
return fmt.Sprintf("Name: %s, Age: %d", p.Name, p.Age)
}
func main() {
var p *Person = nil // 具体类型的 nil 指针
var i interface{} = p // 赋值给接口
fmt.Println(i) // output: <nil Person>，正常调用`String()`方法
}这里 i 虽然不是一个“空接口值”，但它保存了 *Person 的类型信息，所以 fmt.Println(i) 仍然可以正确分派到 (*Person).String()，最终输出 <nil Person>。
也就是说，Go 并不是单纯在保存一个“是否为空”的状态，而是在保存“一个带有类型上下文的运行时容器”。这对以下几件事都很重要：
- 方法动态派发的正确性
- 接口行为的一致性
- 反射系统能够拿到完整类型信息
最常见的坑：返回 error 时出现“假 nil”
这个问题在真实项目里最常见的爆点，就是返回 error 接口。因为 error 本身就是接口类型，如果你返回的是“某个具体错误类型的 nil 指针”，它装进接口后就可能变成非 nil。
func returnsError() error {
var p *MyError = nil // 具体类型的 nil
return p // 此时 error != nil!
}
func main() {
err := returnsError()
if err != nil { // 条件成立！虽然返回的 p 是 nil
fmt.Println("Unexpected error:", err)
}
}从调用方视角看，这种情况最迷惑，因为代码表面上完全符合“返回 nil 表示无错误”的习惯，但实际返回的是“带有 *MyError 类型信息的接口值”。因此 err != nil 会成立。
这类问题一旦出现在业务逻辑、重试流程或者 HTTP 返回处理中，排查成本通常不低，因为日志里看起来像“错误对象是空的”，但分支已经走到错误处理去了。
怎么避免这类 nil 接口陷阱
工程上最稳妥的思路，是尽量在接口边界上返回“真正的 nil 接口值”，而不是“具体类型的 nil 指针”。原文里的几种做法都很实用。
1. 直接返回明确的 nil
这是最推荐的方式。只要表示“没有错误”，就直接返回接口级别的 nil：
func safeReturn() error {
if condition {
return nil // 真正的 nil 接口
}
return errors.New("error")
}这样返回值不会携带额外的具体类型信息，调用方用 err != nil 判断时也最符合直觉。
2. 必要时用类型断言辨认“假 nil”
如果你接手的是历史代码，或者接口返回值已经有既定结构，可以在判空后继续做一次具体类型断言：
if err != nil {
if myErr, ok := err.(*MyError); ok && myErr == nil {
// 处理"假 nil"情况
}
}这种写法适合用于兼容已有逻辑，但它更像补救措施，不适合作为常规风格大面积推广。
3. 通过反射检查底层值是否为 nil
在排查问题、调试运行时状态时，反射也能提供帮助：
fmt.Println(reflect.ValueOf(err).IsNil()) 不过这里也要注意，反射适合做诊断和特殊场景处理，不适合替代正常的接口设计。日常代码里，优先仍然应该是返回正确的接口值。
理解这个问题后，应该记住什么
Go 里的接口不是单一指针，而是“类型信息 + 数据指针”的组合，这正是 nil 接口判断与普通指针判断不同的根源。
所以，看到“一个 nil 指针装进接口后不再等于 nil”，不必把它当成反直觉的例外规则。更准确的理解应该是：
- 具体值为
nil，不代表接口值本身为nil - 接口判空看的是整体结构，而不只是底层数据
- 只要接口还保留着具体类型信息，它就不是一个真正的
nil接口
把这层模型想清楚后，error 返回值、interface{} 传参、反射输出以及 nil 方法调用这些行为，基本都会变得顺理成章。
