Go 接口里放入 typed nil 后为什么不等于 nil

Go 里最容易误判的一类空值，是把一个 typed nil 放进接口：底层指针确实是 nil，但接口比较结果却是非 nil。原因不是 Go 忽略了空指针，而是接口值同时保存动态类型和动态值；只有两者都未设置时，接口本身才等于 nil。

先看接口值为什么保留动态类型

把接口想成两格信息：一格是动态类型，一格是动态值。未赋值的接口两格都为空，所以等于 nil；把 (*MyError)(nil) 赋给接口后，动态类型已经是 *MyError，动态值才是空指针。因此它不是一个“完全为空”的接口。

把 typed nil 放进 error 时怎么定位

这个问题最常见于返回自定义错误。函数签名返回的是 error，但实际返回了一个值为 nil 的错误指针。调用方看到的 err 已经装入了动态类型，所以直接比较会得到非 nil：

package main

import "fmt"

type MyError struct{}

func (*MyError) Error() string { return "业务错误" }

func load() error {
	var p *MyError = nil // 底层指针为空，但类型仍是 *MyError
	return p              // 转成 error 后，接口保留动态类型
}

func main() {
	err := load()
	fmt.Println(err == nil) // false：error 接口并不为空
	if typed, ok := err.(*MyError); ok && typed == nil {
		fmt.Println("底层是 typed nil") // 只有断言后才能检查指针本身
	}
}

修复返回方通常比调用方补判断更可靠：没有错误就直接返回字面量 nil，不要返回一个 nil 的错误指针。调用方若必须兼容外部实现，可以先做类型断言，再判断断言出的指针；这一步要明确知道允许哪些错误类型。

按使用场景选择安全判断方式

直接写 err == nil 适合检查“接口是否完全为空”，它也是 error API 的默认契约。若问题是判断某个已知指针类型的底层值，就使用类型断言：

func isNilMyError(err error) bool {
	if err == nil { // 先排除完全为空的接口
		return true
	}
	p, ok := err.(*MyError) // 只接受约定的具体错误类型
	return ok && p == nil   // 再检查动态值
}

需要同时支持指针、切片、映射、函数或通道等多种可为 nil 的动态类型时，才考虑 reflect.Value，并先用 IsValid 与 Kind 防止对不可判空类型调用 IsNil。反射能扩大覆盖面，也会让契约更隐蔽，不能当成所有接口的默认修复。

在 API 边界建立 nil 契约

排查这类问题时，先问三个问题：返回值是否是接口类型？接口里是否可能装入指针？调用方判断的是接口为空，还是底层对象为空？把答案写进函数注释和测试名称，比在每个调用点堆反射更容易维护。

• 错误返回：成功路径返回字面量 nil，不要返回 typed nil。
• 接口入参：如果允许 typed nil，文档要说明方法是否可调用，避免方法内部解引用崩溃。
• 测试断言：同时覆盖完全 nil、非 nil 具体值、typed nil 三种状态。

相关问题

空接口和 error 的 typed nil 规则不同吗？

规则相同。any 只是空接口的别名，仍然会保存动态类型和动态值。

nil slice 放进接口也会这样吗？

会。nil slice 作为动态值放入接口后，接口有了 slice 动态类型，因此接口本身不等于 nil；要先断言成 slice 再比较。

errors.Is 能判断 typed nil 吗？

errors.Is 用于错误链匹配，不会替代接口 nil 契约。先保证返回方不产生 typed nil，再按错误链语义使用它。

小结：看到“指针是 nil 但接口不是 nil”，先检查动态类型是否已经写入接口。能修返回边界就不要把复杂判断推给调用方；必须兼容时，按已知类型断言，最后才使用反射。