Go 中接口 nil 判断的常见陷阱与正确实践

在 go 中，一个实现了 error 接口的 nil 指针（如 *goof(nil)）传入 error 类型参数后，`err == nil` 仍为 false——因为接口值由类型和值共同构成，`(*goof, nil)` 不等于 `(nil, nil)`。

这是 Go 语言中一个经典且易被忽视的细节：接口值（interface value）的 nil 性，取决于其底层的类型和值是否同时为 nil，而非仅看动态值是否为空。

接口的底层结构

Go 中每个接口值在内存中由两个字宽组成：

• 动态类型（dynamic type）：具体实现该接口的类型（如 *Goof）；
• 动态值（dynamic value）：该类型的实例（如 nil 指针）。

只有当二者均为 nil 时，接口值才真正为 nil。例如：

表达式	类型部分	值部分	接口值是否为 nil
var err error	nil	nil	✅ 是
var g *Goof; TestError(g)	*Goof	nil	❌ 否 —— 类型已确定，非空

因此，TestError(g) 中传入的是 (*Goof, nil)，而 err == nil 实际比较的是 (*Goof, nil) == (nil, nil)，类型不匹配，结果恒为 false。

正确写法示例

✅ 推荐方式：直接使用 error 类型声明或返回

func main() {
    var err error // 零值即为 (nil, nil)
    TestError(err) // 输出："Error is nil"

    // 或在函数中显式返回 nil error
    result := doSomething()
    if result != nil {
        fmt.Println("Got error:", result.Error())
    }
}

func doSomething() error {
    var g *Goof
    if g == nil {
        return nil // ✅ 返回真正的 nil error
    }
    return g
}

❌ 错误示范（触发陷阱）：

func badExample() error {

    var g *Goof // nil
    return g // ❌ 返回 (*Goof, nil)，不是 nil interface！
}

扩展理解：类型敏感的接口比较

该规则不仅限于 error，所有接口比较均遵循此逻辑。例如：

type Bob int
var x int = 42
var y Bob = 42
var ix, iy interface{} = x, y
fmt.Println(ix == iy) // false —— (int, 42) ≠ (Bob, 42)

即使底层数据相同，类型不同即视为不同接口值。

最佳实践总结

• ✅ 永远用 return nil 表示无错误，而非返回一个 nil 指针变量；
• ✅ 接收 error 参数时，信任 if err != nil 判断，但确保上游调用方返回的是真正的 nil（而非带类型的 nil）；
• ✅ 若需构造自定义 error 实例，优先使用 errors.New() 或 fmt.Errorf()，或定义无指针接收者的 error 类型（避免隐式指针化）；
• ⚠️ 避免将未初始化的结构体指针（如 var g *Goof）直接赋值给 error 变量——除非你明确需要非-nil 的 error 实例。

理解接口的双字宽本质，是写出健壮 Go 错误处理代码的关键一步。