在 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 错误处理代码的关键一步。
