Go 接口不等于 nil 却调用失败是什么原因

排查 Go 接口调用失败时，先不要只看 if err != nil。接口值包含动态类型和动态值两部分：只有两部分都没有内容时，接口才等于 nil；如果把一个值为 nil 的 *MyError 放进 error，接口仍然携带 *MyError 这个动态类型，所以比较结果可能是非 nil，后续方法调用也可能进入一个不接受 nil 接收者的实现。

接口的 nil 要同时看动态类型和值

把接口想成一个装着两项信息的容器更容易排查：一项是动态类型 T，另一项是动态值 V。直接声明但尚未赋值的接口是 (T=nil, V=未设置)，因此等于 nil。而赋值 var p *MyError = nil 后，执行 var err error = p，得到的是 (T=*MyError, V=nil)。

这两种状态的关键差别不在“指针值看起来是不是 nil”，而在接口是否还保留了具体类型。Go 规范明确区分接口变量的静态类型和运行时动态类型；官方 FAQ 也用 nil error 说明了同一条规则。

用最小例子拆开两种 nil

下面的例子只展示语义，不依赖任何框架：

package main

import "fmt"

type MyError struct{}

var ErrBad = &MyError{}

func (e *MyError) Error() string {
    if e == nil {
        return "没有具体错误对象"
    }
    return "业务错误"
}

func main() {
    var empty error
    var p *MyError
    var typed error = p

    fmt.Println(empty == nil) // true
    fmt.Println(typed == nil) // false

    if value, ok := typed.(*MyError); ok {
        fmt.Println(value == nil) // true
    }
}

类型断言的两个返回值很适合做定位：ok 说明动态类型是否匹配，断言后的 value == nil 才是在检查具体指针。若直接写 typed.(*MyError).SomeMethod()，即使断言成功，也不能推断接收者一定可用。

返回 error 时避免把 typed nil 传出去

最常见的事故发生在函数返回具体错误指针，但签名返回 error：

func returnsError() error {
    var p *MyError
    if hasProblem() {
        p = ErrBad
    }
    return p // p 为 nil 时，返回的 error 仍可能是非 nil
}

func returnsErrorSafely() error {
    if hasProblem() {
        return &MyError{}
    }
    return nil
}

修复点不是给比较语句加更多判断，而是让函数边界表达正确的结果。成功分支显式返回无类型的 nil，调用方的 err == nil 才能得到预期含义。若业务确实需要从错误接口中取出具体指针，应使用带 ok 的类型断言或 errors.As，并继续判断目标指针是否为 nil。

按接口边界排查调用失败

遇到“接口不等于 nil，但调用失败”时，可以按下面的顺序缩小范围：

1. 先记录接口的动态类型，确认它是不是 *MyError、*Service 等指针类型，而不是把接口比较结果当成对象健康状态。
2. 再用 value, ok := x.(*MyError) 判断类型断言；ok=false 是类型不匹配，ok=true 仍要判断 value == nil。
3. 最后看方法的接收者契约。方法内部若解引用字段，nil 接收者会触发 panic；方法若明确处理 nil，则它可以安全返回，但这属于实现选择，不是接口自动保证。

func inspect(x error) {
    if x == nil {
        return
    }
    value, ok := x.(*MyError)
    if !ok {
        return // 动态类型不是 MyError
    }
    if value == nil {
        return // 接口非 nil，但具体指针为 nil
    }
    _ = value.Error()
}

因此，“接口非 nil”只完成了第一层判断。真正可靠的修复通常发生在生产者返回值的地方：统一用 error 作为错误签名、成功路径显式 return nil，并为允许 nil 接收者的方法写清楚行为。

常见问题

为什么把 nil 指针赋给 interface 后就不等于 nil？

因为赋值时接口保留了指针的动态类型；接口只有动态类型和值都未设置时才是 nil。

类型断言成功能说明对象一定存在吗？

不能。断言成功只说明动态类型匹配，指针本身仍可能为 nil，所以还要单独判断具体值。

所有 nil 接收者调用都会 panic 吗？

不会。方法可以主动处理 nil 接收者；但如果实现访问了 nil 指针指向的字段，就可能发生运行时 panic，调用方不能靠接口比较替代契约检查。