Go interface 与多态：隐式实现、方法集与 nil 陷阱

前置：08 标准项目布局（或至少读完 02）
目标：理解 Go 的「隐式接口」——定义小接口、用接口解耦存储与业务，跑通多态 demo。

心智模型

Go 没有 implements 关键字。只要类型实现了接口要求的全部方法，就自动满足该接口。

业务代码依赖「接口」
        │
        ▼
   Notifier 接口
   ├── EmailNotifier
   └── SlackNotifier   ← 可随时替换实现，业务不用改

口诀：

1. 面向接口编程，面向小接口（一个方法的接口最常见，如 io.Reader）
2. 接口定义在使用方附近，而不是实现方硬塞大而全接口
3. 接受接口、返回具体类型（入参抽象、出参具体）——经验法则，非绝对

接口不是「为了多态而多态」。它的价值在于：调用方只依赖自己需要的行为，实现方可以独立替换、独立测试。

最小例子

type Speaker interface {
	Speak() string
}

type Dog struct{}

func (Dog) Speak() string { return "汪" }

func Say(s Speaker) { fmt.Println(s.Speak()) }

Dog 从没写过 implements Speaker，但能传给 Say。编译器在赋值时检查方法集，缺一个方法就报错。

动手：可替换的通知器

业务只依赖 Notifier，运行时用命令行参数切换 email / slack。

cd golang/09-interfaces/demo
go run .
# [email from=orders@example.com] 通知: 订单已创建: 机械键盘

go run . -via=slack
# [slack #orders] 通知: 订单已创建: 机械键盘

go run . -via=foo
# 未知通道: foo（标准错误，退出码 1）

关键点：

type Notifier interface {
	Notify(msg string) error
}

func PlaceOrder(n Notifier, item string) error {
	return n.Notify("订单已创建: " + item)
}

main 里根据 flag 选具体实现，业务函数签名始终是 Notifier：

var n Notifier
switch *via {
case "email":
	n = EmailNotifier{From: "orders@example.com"}
case "slack":
	n = SlackNotifier{Channel: "orders"}
default:
	fmt.Fprintf(os.Stderr, "未知通道: %s\n", *via)
	os.Exit(1)
}

EmailNotifier 和 SlackNotifier 都没有声明实现关系，它们只是各自有 Notify(string) error 方法。PlaceOrder 不知道也不关心具体是哪一个。

深入 1：隐式接口与编译期检查

隐式实现让包之间可以互不依赖：main 定义 Notifier，具体类型甚至不需要 import 这个接口所在的包。代价是「实现了没有」不会在类型定义处显式写出来，所以常用编译期断言：

var _ Notifier = EmailNotifier{}
var _ Notifier = (*SlackNotifier)(nil)

var _ T = expr 把 expr 赋给空白标识符，仅用于让编译器检查类型。放在实现附近，修改方法签名时能立刻发现不满足接口。

注意：断言只能证明「当前版本满足」，不能防止未来删方法。它仍然比等到运行时 panic 好得多。

深入 2：方法集与指针接收者

接口匹配看的是方法集：

接收者写法	T 的方法集	*T 的方法集
func (t T) M()	包含 M	包含 M
func (t *T) M()	不包含	包含 M

所以：

type Counter struct{ n int }

func (c *Counter) Inc() { c.n++ }

var _ interface{ Inc() } = &Counter{} // 可以
// var _ interface{ Inc() } = Counter{} // 编译失败

值接收者方法操作的是副本，适合不修改状态的小类型；指针接收者能修改原值，也避免大结构体复制。一旦某个类型有指针接收者方法，通常统一用指针接收者，避免方法集一半在 T、一半在 *T 的混乱。

一个容易混淆的点：直接调用 c.Inc() 时，如果 c 是可寻址变量，编译器会自动取地址；但把 c 装进接口时不会自动补这一步，必须显式传 &c。

深入 3：小接口与 io.Reader / io.Writer

标准库最著名的接口都很小：

type Reader interface {
	Read(p []byte) (n int, err error)
}

type Writer interface {
	Write(p []byte) (n int, err error)
}

os.File、bytes.Buffer、strings.Reader、net.Conn 都实现了它们，所以同一个函数可以处理文件、内存和网络数据（标准库扩展示例）：

func copyTo(w io.Writer, r io.Reader) error {
	_, err := io.Copy(w, r)
	return err
}

io.Copy 只依赖 Reader 和 Writer，不关心底层是文件还是 socket。这就是小接口的威力：接口越小，能满足它的类型越多，复用面越广。

自己定义接口时也先问：真的需要五个方法吗？通常一个方法就够。把 Read、Write、Close 拆开，调用方只声明自己用的那个，测试也更容易造假实现。

深入 4：类型断言与 type switch

接口值里装着具体类型。要取回具体值，用类型断言：

v, ok := x.(string) // comma-ok：失败时 v 为零值，ok 为 false，不 panic
s := x.(string)     // 单值形式：失败直接 panic

优先用 comma-ok。只有在你已经确定类型、失败属于程序 bug 时才用单值形式。

多个类型分支用 type switch：

switch v := x.(type) {
case string:
	fmt.Println("string", v)
case int:
	fmt.Println("int", v)
case nil:
	fmt.Println("nil interface")
default:
	fmt.Printf("other %T\n", v)
}

type switch 里的 v 在每个 case 中是对应具体类型，不是接口类型。case nil 只匹配真正的 nil 接口，不匹配「装着 nil 指针的接口」。

日常业务优先用具体小接口表达行为，少用裸 any 做类型分发；类型断言适合处理边界数据，比如 JSON 解码后的 map[string]any。

深入 5：nil interface 陷阱

接口值由两部分组成：动态类型 + 动态值。只有两者都为空，接口才等于 nil。

var p *MyError = nil
var err error = p

fmt.Println(err == nil) // false
fmt.Printf("%T\n", err) // *main.MyError

err 的动态类型是 *MyError，所以 err != nil。这是 Go 最常见的坑之一：函数返回 error 时，不要返回一个可能为 nil 的具体指针：

func do() error {
	var e *MyError // nil
	return e       // 返回的 error 不是 nil
}

正确做法是显式返回 nil：

func do() error {
	var e *MyError
	if e == nil {
		return nil
	}
	return e
}

另外，调用「装在接口里的 nil 指针」的方法不一定会 panic：如果方法内部不解引用接收者，可以正常返回；一旦访问字段就会 panic。不要依赖这种细节，发现 %T 不是 <nil> 就尽早处理。

深入 6：依赖倒置、接口位置与 mock

demo 里 Notifier 定义在使用方 main 包，而不是定义在 EmailNotifier 旁边。这是有意为之：

• 使用方最清楚自己需要什么方法；
• 实现方不需要 import 接口包，依赖方向从「实现 → 抽象」变成「双方 → 抽象」；
• 测试可以只实现使用方要求的最小方法。

测试里的假实现通常几行就够：

type fakeNotifier struct {
	msgs []string
	err  error
}

func (f *fakeNotifier) Notify(msg string) error {
	f.msgs = append(f.msgs, msg)
	return f.err
}

func TestPlaceOrder(t *testing.T) {
	f := &fakeNotifier{}
	if err := PlaceOrder(f, "键盘"); err != nil {
		t.Fatal(err)
	}
	if len(f.msgs) != 1 {
		t.Fatalf("got %d messages", len(f.msgs))
	}
}

接口隔离同样重要：不要定义 UserStore 这种包含增删改查十个方法的胖接口，然后让每个测试都实现一遍。按调用方拆成 UserReader、UserWriter，需要哪个用哪个。

常见坑

坑	现象 / 处理
接口值为 (*T)(nil)	iface == nil 为 false（类型信息非空）
方法集在指针上	func (p *T) M() 时，只有 *T 满足接口，T 不满足
大接口难 mock	拆成小接口，测试用假实现即可
返回接口而不是具体类型	调用方看不到具体方法；构造函数优先返回 *T
接口值比较	动态类型不可比较（如 slice）时，== 会 panic
用 any 代替设计	类型断言散落各处，编译期检查丢失

调试 / 排错清单

1. 编译期加 var _ Notifier = (*T)(nil)，先让编译器帮你检查。
2. 用 fmt.Printf("%T %v\n", v, v) 看接口的动态类型和值。
3. err != nil 但打印是 nil，检查是不是返回了 typed nil。
4. 方法调用报「does not implement」，先对比方法签名和接收者类型。
5. 用 errors.As 取错误链里的具体类型，别用字符串比较。
6. 测试里优先手写 fake，不要为了一个方法引入 mock 框架。

demo 在练什么 / 练习

demo 练的是：定义使用方接口、让两个类型隐式实现、在 main 运行时选择实现、业务函数只依赖接口。

练习：

1. 增加 SMSNotifier，实现 Notify，-via=sms 时使用它。
2. 让 EmailNotifier.Notify 在 From 为空时返回错误，并在 PlaceOrder 里处理。
3. 给 Notify 写一个返回固定错误的 fake，验证 PlaceOrder 会把错误传出去。
4. 把 Notifier 改成两个方法的接口，观察哪些实现需要补方法。
5. 写一个返回 *EmailNotifier(nil) 的函数，观察 error / 接口判空行为。

小结

概念	记住一句
隐式实现	有方法就满足，无需声明
小接口	一个方法往往够用
方法集	指针接收者只属于 *T
依赖倒置	业务依赖抽象，main 组装具体
nil 接口	类型和值都为空才等于 nil
接口位置	定义在使用方，不定义在实现方

下一篇：10 泛型基础

---

如果这篇对你有帮助，欢迎点赞、收藏，关注专栏「Go 从零到熟练」；有问题欢迎在评论区交流。

转载自 CSDN-专业IT技术社区

原文链接：https://blog.csdn.net/huangjuan0229/article/details/170485779