Go 返回 error 为 nil 但判断 err != nil 为什么成立

有时日志打印出 err 像是 nil，但紧接着的 if err != nil 却进入了错误分支。这个现象通常不是比较语句失效，而是把一个值为 nil 的具体指针放进了 error 接口：接口仍然保留了动态类型，所以接口本身并不等于 nil。

error 为什么会出现“看起来是 nil”但比较不相等

Go 规范把接口变量区分为静态类型、动态类型和动态值。对 error 来说，最容易漏掉的是：接口里装入一个具体类型后，动态类型不会因为具体值为 nil 而消失。

package main

import "fmt"

type MyError struct{}

func (e *MyError) Error() string { return "自定义错误" } // 让 *MyError 实现 error

func main() {
	var p *MyError = nil                 // 具体指针的值是 nil
	var err error = p                    // 转成接口后仍记录动态类型 *MyError
	fmt.Println(p == nil)                // true：比较的是具体指针
	fmt.Println(err == nil)              // false：接口中仍有动态类型
	fmt.Printf("%T %#v\n", err, err)    // *main.MyError (*main.MyError)(nil)
}

这里的 err 可以理解成一对信息：(动态类型=*MyError, 动态值=nil)。而真正的 nil 接口更接近 (动态类型=nil, 动态值=nil)。接口比较时，动态类型和动态值都要符合 nil 的条件；只剩下动态值为 nil，还不够。

沿返回链定位 typed nil 的来源

排查时不要只看调用方的 err != nil，要沿着“具体类型返回值 → error 接口 → 调用方”检查一次。最典型的来源是函数先返回 *MyError，调用者再把它当成 error 接收。

type MyError struct{ Message string }

func (e *MyError) Error() string { return e.Message } // 具体类型提供 Error 方法

func makeError(ok bool) *MyError {
	if ok {
		return nil // 这里是具体指针层面的 nil
	}
	return &MyError{Message: "请求失败"} // 非 nil 指针才携带错误内容
}

func load() error {
	err := makeError(true) // err 的静态类型是 *MyError
	return err             // 转成 error 后会留下动态类型 *MyError
}

load 的返回值是 error，所以 return err 会发生接口转换。此时返回给调用方的不是“空接口”，而是装着 nil 指针的接口。日志若只打印底层值，容易让人误以为比较结果也应该是 true。

在返回边界把 nil 语义修正回来

最稳妥的修复是：在具体指针还没有转换成接口前判断 nil。只要没有错误，就显式返回真正的 nil；有错误时再把非 nil 指针返回给 error。

func loadFixed() error {
	err := makeError(true) // 先保留具体类型，便于判断指针是否为空
	if err == nil {
		return nil // 返回接口层真正的 nil，而不是 (*MyError)(nil)
	}
	return err // 只有非 nil 指针才转换为 error
}

如果函数本身不需要暴露 *MyError 的额外方法，也可以直接把签名改成返回 error，并在函数内部的具体分支中返回 nil。关键不在于“多写一个 if”，而在于让 nil 的判断发生在接口转换之前。

用两条测试路径防止回归

最小测试至少覆盖“没有错误”和“确实有错误”两条路径。测试断言放在调用方，因为真正需要稳定的是调用者看到的 error 语义。

func TestLoadFixed(t *testing.T) {
	err := loadFixed()
	if err != nil {
		t.Fatalf("无错误时应返回 nil，实际得到 %T", err) // 防止 typed nil 回归
	}

	fail := func() error { return &MyError{Message: "请求失败"} }
	err = fail()
	if err == nil {
		t.Fatal("有错误时不应返回 nil") // 确认非 nil 错误仍能被发现
	}
}

如果业务需要保留具体错误类型，使用 errors.As 做类型提取，但不要用反射把 typed nil 当成正常返回值掩盖掉。日志也应同时记录错误类型与错误文本，这样能区分“接口不为 nil”与“错误对象内部字段为空”。

常见问题

只要看到 fmt.Println(err) 打印 nil，就能认定 err == nil 吗？

不能。打印结果可能来自底层指针的格式化。应直接比较 err == nil，必要时用 %T 记录动态类型。

把 error 改成 interface{} 能解决问题吗？

不能，这只会换一个接口类型，仍然可能装入值为 nil 的具体指针。应在具体类型层完成 nil 判断，再返回接口。