卷 III · 接口CH 13深度 13/24

nil 接口的坑，与面向接口设计

本章卸下「接口驱动」的大接口预规划

接口卷最后一章，讲两件事。前半章是个坑：接口值其实是「两个字」——一个类型、一个值——只有两个都是 nil 接口才等于 nil。于是会出现「你返回了一个 nil 指针，上层判 err != nil 却成立」的著名 bug，Go FAQ 专门列了它。后半章是几条把接口用好的实战准则，把这一卷收成你能落地的手艺。

nil 接口类型/值两个字接口设计accept interfaces

接口值是「两个字」

要理解那个 nil 坑，得先看接口在内存里的样子。一个接口值不是一个简单的指针，它是两个字（two words）：

// 接口值在内存里，概念上是这样一对：
( 动态类型,  动态值 )
   type       value
  • 类型那一格：记录「这个接口现在装的是什么具体类型」（比如 *os.File、*MyErr）。
  • 值那一格：指向那个具体值的数据。

比如 var w io.Writer = os.Stdout，这个接口值就是 (*os.File, 指向 stdout 的指针)。而一个真正的 nil 接口，是两格都空：(nil, nil)。这个「两个字」的结构，是下面整个坑的根源。

◆ 接口 == nil，当且仅当两格都是 nil

err == nil 成立的条件是：类型那一格和值那一格都是 nil。只要类型那一格被填上了——哪怕值那一格是个 nil 指针——接口就不等于 nil。

记住这句话，你就掌握了 Go 里最坑人的那个 bug 的全部原理。

亲眼看这个坑

下面这台 Demo 把接口的「两个字」画出来，切换三种返回方式，看 err == nil 的结果怎么变：

看第二个例子，这就是那个经典 bug：

type MyErr struct{ msg string }
func (e *MyErr) Error() string { return e.msg }

func do() error {
    var p *MyErr = nil    // p 是一个 nil 的 *MyErr 指针
    return p              // 把它当 error 返回
}

func main() {
    err := do()
    fmt.Println(err == nil)   // false ！！你以为是 true 吧
}

拆解一下：do() 返回时，那个 nil 的 *MyErr 被塞进 error 接口。接口值变成了 (*MyErr, nil) —— 类型那一格被填成了 *MyErr，只有值那一格是 nil。按上面的规则，类型格不空，所以 err != nil。于是上层 if err != nil 成立，你的程序以为「出错了」，但其实那个「错误」是个 nil，你一 err.Error() 就 panic。这个 bug 极其隐蔽，因为一切看起来都「应该」是 nil。

⚠ 铁律：要返回「没有错误」，就直接 return nil

根治办法只有一条：永远不要返回一个「恰好为 nil 的具体指针」当接口用。要表达「没有错误 / 没有值」，就直接 return nil（返回接口字面量的 nil），而不是 return p（p 是个 nil 的具体指针）。

所以正确写法是：if 出错 { return &MyErr{...} }，正常路径直接 return nil —— 别搞一个 var p *MyErr 中转。这也是为什么 Go 代码里错误处理几乎总是 return nil 结尾，而不是返回某个碰巧为 nil 的变量。Go FAQ 里专门有一条讲这个坑，可见栽的人之多。

后半章：怎么把接口用好

坑讲完，来点正向的手艺。你带着 Java 的「面向接口编程」习惯来，但 Go 的接口用法和那套很不一样。几条经过社区反复锤炼的准则：

准则一：接口要小，最好一两个方法

第 9 章的谚语「接口越大抽象越弱」，落到实践就是：别设计大接口。Go 标准库里最有生命力的接口全是单方法的 —— io.Reader、io.Writer、fmt.Stringer、sort.Interface（3 个）。一个单方法接口，几乎任何相关类型都能轻松满足，组合起来极灵活。你要更强的能力，用嵌入把小接口拼起来（第 12 章），而不是一开始就列一个七八方法的巨无霸。

准则二：在「用的地方」定义接口，别在「实现的地方」

这是第 9 章那句「接口属于消费者」的落地。谁需要某种行为，谁就在自己身边定义那个小接口，而不是让提供方预先发布一套接口。举例：

// ❌ Java 味：先在 store 包里发布一个大接口，让所有实现去实现它
// ✅ Go 味：我这个函数需要「能按 ID 查用户」，我就地定义我需要的那一点点

// 在 handler 包里，紧挨着用它的函数
type userFinder interface {
    FindUser(id int) (*User, error)
}

func handle(f userFinder, id int) { ... }   // 我只要求这一个方法

好处：handle 只依赖它真正需要的那一个方法，任何有 FindUser 的东西都能传进来（真实的数据库、测试用的 mock、缓存层……），而且这些实现压根不需要知道 userFinder 这个接口存在。这就是结构化接口 + 小接口 + 消费者定义三者合力的甜头，测试尤其受益（mock 一个单方法接口太容易了）。

◆ 准则三：接受接口，返回具体类型

Go 社区一句流传很广的话：「Accept interfaces, return structs.」—— 函数参数尽量用接口（灵活，什么实现都能传进来），函数返回值尽量用具体类型（诚实，调用方拿到全部能力、清楚地知道自己拿到了什么）。

为什么返回值别用接口？因为返回一个接口，等于提前把调用方能用的能力砍到只剩接口那几个方法，还容易踩上面那个「返回 nil 具体类型」的坑。返回具体类型 *Client，调用方想当接口用随时能赋值给接口变量，主动权在他手里。入口放宽（接口），出口给足（具体类型）——这条准则能帮你避开一大半接口设计的别扭。

准则四：别为了「以后可能有多个实现」提前抽接口

从 Java 来的人有个强烈冲动：写个 UserService，立刻配一个 UserServiceImpl 和一个 IUserService 接口，「万一以后要换实现呢」。Go 社区明确反对这种预防性抽象。因为结构化接口让你可以随时、事后为一个已存在的具体类型抽出接口 —— 真到了需要第二个实现、或者要 mock 的那天，再抽也完全来得及，而且那时你知道接口到底该长什么样。没有当下的需求，就别造接口。一个只有一个实现的接口，通常是过度设计。

Kotlin 对照

⇄ 接口驱动设计的两种打法

Java / Kotlin 的「面向接口编程」是自上而下的：先设计接口契约（常常配 DI 框架），再写实现，接口和实现往往在生产者那侧成对出现（Repository + RepositoryImpl）。接口是提前规划的架构骨架。这套在大型企业项目里很成熟，但也盛产「一个实现配一个接口」的样板和过度抽象。

Go 的接口用法是自下而上、按需浮现的：先写具体类型把事做出来，等某处真的需要「可替换的行为」时，就地在消费者那侧抽一个尽量小的接口。接口是从具体需求里长出来的，不是预先画出来的。

迁移时要压住两个 Java 惯性：一是「先抽接口再写实现」的顺序（Go 里反过来，先具体后抽象）；二是「接口越完整越好」的审美（Go 里越小越好）。还有那个 nil 接口坑 —— 它是 Kotlin 完全没有的（Kotlin 的 null 就是 null，不存在「装了 null 却不是 null」的两字结构）。记住那条铁律 return nil，你就绕开了它。把这些调过来，你写出的 Go 接口就是地道的，而不是「披着 Go 皮的 Java」。

这一章的一句话

接口值是「类型 + 值」两个字，只有两格都 nil 接口才等于 nil，所以要返回「无错误」永远直接 return nil，别返回碰巧为 nil 的具体指针；用好接口的准则是——接口尽量小、在消费者一侧按需定义、接受接口返回具体类型、别为「以后」提前抽象。

卷 III 到此结束 —— 你已经拿下了 Go 最难也最值钱的部分。接下来卷 IV 短小但重要：Go 怎么处理错误。你会正面撞上那个从第 1 章就欠着的账 ——「没有 try/catch」到底是什么体验。