Go 接口：从隐式实现到约束类型集

面向有 Java 经验的开发者，基于 Go 1.26。

Go 接口的语法不难，真正容易出错的是使用边界。它没有 implements，类型声明时也不必预先知道自己会被哪些调用方使用；只要方法集满足要求，这个类型就实现了接口。由于实现关系是结构化且隐式的，接口可以由使用方按自身需要定义，小接口也因此更容易发挥解耦作用。

Go 1.18 引入泛型后，“接口”又多了一项职责：描述类型集合和运算约束。运行时接口值与泛型约束使用相似的声明语法，背后的模型却不相同。阅读现代 Go 代码时，第一步就是确认眼前的接口究竟用于运行时分派，还是编译期约束。

目录

• 1. 两种接口用途
• 2. 基本接口与隐式实现
• 3. 接口值的运行时模型
• 4. 方法集决定是否实现
• 5. nil 接口陷阱
• 6. 类型断言
• 7. 类型 switch
• 8. 接口嵌入与组合
• 9. 空接口与 any
• 10. comparable 与可比较性
• 11. 约束接口与类型集合
• 12. 泛型与接口如何选
• 13. API 设计
• 14. 错误接口
• 15. 适配、装饰与测试替身
• 16. 性能、分配与并发
• 17. 与 Java 对照
• 18. 常见误区
• 19. 速查表
• 可运行示例
• 20. 练习
• 21. 官方资料

1. 两种接口用途

1.1 运行时行为接口

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

这是基本接口，可以作为变量、字段、参数和返回类型。接口值在运行时携带某个具体值，调用方法时发生动态分派。

1.2 编译期约束接口

type Integer interface {
	~int | ~int8 | ~int16 | ~int32 | ~int64
}

func Sum[T Integer](values []T) T { /* ... */ }

这个接口包含类型元素，只能用作类型参数约束，不能声明普通变量：

// var x Integer // 不允许：Integer 不是基本接口

约束接口描述“允许哪些类型、可以做哪些操作”，泛型实例化后通常不需要保存运行时接口值。

判断时可以直接问：这里需要在运行时接收不同实现，还是要在编译期让一段算法适用于一组类型？前者考虑行为接口，后者考虑泛型约束。

2. 基本接口与隐式实现

定义接口只需列出方法：

type Notifier interface {
	Notify(message string) error
}

type EmailNotifier struct {
	Address string
}

func (e EmailNotifier) Notify(message string) error {
	fmt.Printf("send %q to %s\n", message, e.Address)
	return nil
}

EmailNotifier 没有声明 implements Notifier，但方法名、参数、结果完全匹配，所以已经实现：

func SendWelcome(n Notifier) error {
	return n.Notify("welcome")
}

_ = SendWelcome(EmailNotifier{Address: "a@example.com"})

方法签名必须精确一致。Go 没有参数协变、返回值协变，也不会因为两个命名类型底层相同就视为同一方法：

type Message string

type BadNotifier struct{}
func (BadNotifier) Notify(Message) error { return nil }

// BadNotifier 不实现 Notify(string) error。

推荐在实现附近放编译期断言：

var _ Notifier = EmailNotifier{}

如果实现依赖指针方法集：

var _ Notifier = (*EmailNotifier)(nil)

这条声明不会分配对象，也不会在运行时执行，它只要求编译器检查实现关系。

3. 接口值的运行时模型

概念上，一个接口值包含两部分：

(动态类型, 动态值)

var n Notifier
n = EmailNotifier{Address: "a@example.com"}

此时：

• 静态类型是 Notifier，决定编译时可调用哪些方法；
• 动态类型是 EmailNotifier；
• 动态值是那个 EmailNotifier 值。

这只是便于推理的语义模型，并非规范承诺的具体内存布局。代码不应依赖接口在运行时恰好占几个机器字。

3.1 赋值会复制具体值

type Counter struct{ N int }
func (c Counter) String() string { return strconv.Itoa(c.N) }

c := Counter{N: 1}
var s fmt.Stringer = c
c.N = 2
fmt.Println(s.String()) // 1

装入接口的是 c 当时的副本。若装入 &c，接口保存的是指针值，之后能观察同一个对象：

var s fmt.Stringer = &c

若结构体含切片、map 或指针，按值装入接口依然可能共享底层数据。接口不是深复制边界。

3.2 接口之间赋值

一个接口值可以赋给另一个由其动态类型实现的接口：

var r io.Reader = os.Stdin
var x any = r

x 的动态类型仍是具体的 *os.File，而不是“嵌套了一层 io.Reader”。接口保存具体动态值，不会形成无限接口套娃。

4. 方法集决定是否实现

对非接口定义类型 T：

• T 的方法集包含接收者为 T 的方法；
• *T 的方法集包含接收者为 T 和 *T 的方法。

type Buffer struct{}

func (Buffer) Size() int      { return 0 }
func (*Buffer) Write([]byte) error { return nil }

type Sizer interface{ Size() int }
type Writer interface{ Write([]byte) error }

var _ Sizer = Buffer{}
var _ Sizer = (*Buffer)(nil)
var _ Writer = (*Buffer)(nil)
// var _ Writer = Buffer{} // 编译错误

容易困惑的一点是：

b := Buffer{}
b.Write(nil) // 可以

这是因为局部变量 b 可取地址，编译器把调用改写为 (&b).Write(nil)。接口实现判断不会做这层自动取址，因为接口内的动态值通常不可取地址。调用便利和方法集是两套规则。

4.1 嵌入对方法集的影响

结构体嵌入 T 或 *T 后，提升的方法会按规范进入外层值或指针的方法集。规则细节容易记错，工程上最好用断言表达意图：

var _ io.Reader = (*Outer)(nil)

接口嵌入则取方法集合的交集式组合：实现外层接口的类型必须满足其中所有方法。若同名方法签名不同，接口声明本身就是非法的。

4.2 接口的方法集

基本接口的方法集就是它声明及嵌入所得的全部方法。一般接口从类型集合角度定义；一个类型实现接口，当它属于接口的类型集合。对只包含方法的基本接口，这与“拥有全部方法”一致。

5. nil 接口陷阱

接口零值的两部分都为空：

var err error
fmt.Println(err == nil) // true

若把一个 nil 指针装入接口，动态类型不为空：

type MyError struct {
	Message string
}

func (e *MyError) Error() string {
	if e == nil {
		return "<nil MyError>"
	}
	return e.Message
}

var p *MyError = nil
var err error = p
fmt.Println(err == nil) // false

此时接口是 (*MyError, nil)，不是 (nil, nil)。这就是“typed nil”陷阱。

最常见的错误来自返回：

func validate() error {
	var err *MyError
	// ...
	return err // 返回的 error 非 nil
}

正确写法是在没有错误时明确返回 nil：

func validate() error {
	var err *MyError
	// ...
	if err == nil {
		return nil
	}
	return err
}

更好的做法是缩小具体错误指针的作用域，只在真的有错误时创建并返回。

5.1 接口相等

两个接口值相等，需要动态类型相同且动态值相等；接口也可和 nil 比较。若动态值的类型不可比较，比较会 panic：

var a any = []int{1}
var b any = []int{1}
// fmt.Println(a == b) // panic：动态类型 []int 不可比较

因此“接口类型可以写 ==”不等于“任意接口值比较都安全”。业务相等应通过明确方法或类型分支实现。

5.2 是否应该用反射判断 typed nil

通用框架偶尔需要判断接口动态值是否为 nil，可以用反射并只对可 nil 的 Kind 调用 IsNil。普通业务代码不应依靠一个 IsNil(any) 工具掩盖 API 问题；更清晰的返回约定通常能从源头消除陷阱。

6. 类型断言

类型断言只用于接口表达式：

value, ok := x.(T)

若动态类型满足目标，value 是目标类型的值，ok 为 true；否则 value 是目标类型零值：

var x any = "go"
s, ok := x.(string)
fmt.Println(s, ok) // go true

n, ok := x.(int)
fmt.Println(n, ok) // 0 false

省略 ok 时，失败会 panic：

s := x.(string)

只有程序不变量已保证类型，且违反就应立即终止时才适合单值断言。处理外部数据、插件或协议时应使用 comma-ok。

6.1 断言为另一个接口

目标 T 可以是接口：

type Flusher interface{ Flush() error }

if f, ok := writer.(Flusher); ok {
	_ = f.Flush()
}

这叫能力探测。标准库经常使用小型可选接口扩展行为。调用方应保证“未实现”也有合理降级路径，否则能力就不该是可选的。

6.2 指针和值要完全匹配

var x any = User{}
_, okValue := x.(User)  // true
_, okPtr := x.(*User)   // false

动态类型是精确的。User 与 *User 不会因为可取地址规则自动互换。

7. 类型 switch

对多个可能类型分支时使用类型 switch：

func Describe(v any) string {
	switch x := v.(type) {
	case nil:
		return "nil"
	case string:
		return "string: " + x
	case int:
		return strconv.Itoa(x)
	case fmt.Stringer:
		return x.String()
	default:
		return fmt.Sprintf("%T", x)
	}
}

v.(type) 只能出现在类型 switch 的 guard 中。每个分支里的变量静态类型通常是对应 case 的类型；一个 case 列多个类型时，变量保留原接口类型：

switch x := v.(type) {
case int, int64:
	fmt.Printf("%T\n", x) // x 的静态类型仍与 v 相同
}

case 从上到下匹配。具体类型和接口可能重叠时，顺序会影响结果：

case *bytes.Buffer:
case io.Reader:

类型 switch 适合协议边界、格式化和访问者式分派。若核心业务到处根据具体类型 switch，往往说明接口抽象不足，或者真正需要的是显式的和类型模型。

8. 接口嵌入与组合

标准库的组合方式很典型：

type ReadWriter interface {
	Reader
	Writer
}

自定义例子：

type Loader interface {
	Load(context.Context, string) ([]byte, error)
}

type Saver interface {
	Save(context.Context, string, []byte) error
}

type Store interface {
	Loader
	Saver
}

函数只读时依赖 Loader，只写时依赖 Saver，真正需要两者才依赖 Store。这体现了“由消费者定义最小接口”。

8.1 同名方法

嵌入接口中同名方法只有签名完全相同时才能合并：

type A interface{ M(int) string }
type B interface{ M(int) string }
type C interface {
	A
	B
}

签名不同会在声明处报错，而不是等到某个实现出现。

8.2 接口不是字段包

接口应围绕调用方所需行为，而不是复制实现类型所有方法。一个拥有二十个方法的 UserService 接口通常很难实现、测试和演进。把它按用例拆成 UserFinder、UserCreator 等小接口，依赖关系会更准确。

但“小”也不是越碎越好。若几个方法必须共同维持一次事务或协议状态，拆开反而会允许不完整实现。边界应由一致性需求决定。

9. 空接口与 any

any 是 interface{} 的预声明别名：

var a any
var b interface{}

两者完全相同。any 可以保存任何非接口或接口值：

values := []any{1, "go", true}

适用场景：

• 编解码器边界；
• 日志字段值；
• 反射框架；
• 真正异构的数据格式；
• 无法在编译期知道载荷类型的协议。

不适合用来逃避建模：

func Process(input any) any

这种签名没有告诉调用者接受什么、返回什么，错误被推迟到运行时。若输入输出有稳定关系，优先具体类型、行为接口或泛型。

9.1 []any 不是任意切片

strings := []string{"a", "b"}
// var values []any = strings // 不允许

[]string 和 []any 内存表示与赋值语义不同。需要时逐个装箱：

values := make([]any, len(strings))
for i, s := range strings {
	values[i] = s
}

这有 O(n) 时间和潜在分配成本。

10. comparable 与可比较性

comparable 是预声明接口，表示一组可用于 ==、!=，并可作为 map 键的类型。它只能作为约束：

func Index[T comparable](values []T, target T) int {
	for i, v := range values {
		if v == target {
			return i
		}
	}
	return -1
}

布尔、数值、字符串、指针、channel、接口，以及元素可比较的数组和字段可比较的结构体，在语言中可比较；切片、map、函数不可比较（只能和 nil 做受限比较）。

10.1 严格可比较

规范还区分“严格可比较”：排除接口类型，以及含接口成分导致运行时比较可能 panic 的复合类型。comparable 的类型集合以严格可比较的非接口类型为核心。

从 Go 1.20 起，约束满足有一条专门例外，使 any 等可比较接口类型可以满足 comparable 约束。因此下面可以实例化：

_ = Index[any]([]any{1, 2}, 2)

但这不保证所有动态值比较都安全：

values := []any{[]int{1}}
// Index(values, values[0]) 运行到 == 时会 panic。

所以泛型的 comparable 在常见具体类型上提供编译期保证；当实例化参数本身是接口时，仍须理解动态值风险。对外部异构值做键或比较，最好先限定支持类型。

10.2 接口作为 map 键

map[any]V 合法，但插入动态类型不可比较的键会 panic：

m := map[any]string{}
// m[[]int{1}] = "x" // panic

能声明 map 不代表任意动态值都能作键。

11. 约束接口与类型集合

一般接口可以包含方法元素、嵌入接口、类型项、近似项和联合：

type Signed interface {
	~int | ~int8 | ~int16 | ~int32 | ~int64
}

type StringLike interface {
	~string
	Len() int
}

从类型集合看：

• 方法元素筛选拥有该方法的类型；
• T 表示精确类型 T；
• ~T 表示底层类型为 T 的所有类型；
• A | B 表示并集；
• 多行元素表示交集。

约束的用途不仅是“允许哪些类型”，也决定泛型函数体可用什么操作：

type Ordered interface {
	~int | ~int64 | ~float64 | ~string
}

func Min[T Ordered](a, b T) T {
	if a < b {
		return a
	}
	return b
}

< 对类型集合中每个成员都有效，所以允许。

11.1 any 约束

func Clone[T any](v T) T { return v }

any 表示不要求额外操作，不意味着函数体可以对 T 做类型断言。类型参数变量不是接口值：

// v.(string) 非法

确需查看动态类型时可以先转成 any(v)，但频繁这么做通常说明泛型没有带来静态价值。

11.2 联合项限制

联合中的非接口类型项必须按规范保持类型集合不重叠；不能随意同时写 int 和 ~int。comparable 和含方法接口也受到联合项规则限制。遇到复杂约束时，应把它拆成命名约束并让编译器验证，而不是靠记忆拼语法。

11.3 约束不要暴露无意义能力

约束应只包含算法真正使用的运算。为复用一个函数而要求十个方法，会排除本可接受的类型。泛型约束与运行时接口一样，消费者需求应尽可能小而准确。

12. 泛型与接口如何选

这不是“新语法替代旧语法”，而是两个维度：

需求	优先选择
运行时保存不同具体实现	接口
调用相同行为并动态分派	接口
同一种算法保留输入输出的具体类型关系	泛型
对切片、map、数值做静态算法	泛型
异构集合	接口或明确的和类型模型
只为测试替换一个依赖	小接口
实现类型在编译期已知且无异构存储	具体类型或泛型

例如：

func Map[S ~[]E, E, R any](src S, f func(E) R) []R

泛型能保留元素类型关系。若写成 []any，调用方要做断言，且会丢失静态检查。

反过来，io.Reader 的价值就是让文件、网络、缓冲区等在运行时统一被消费，使用接口非常自然。

不要仅为了避免一次虚调用就泛型化业务服务。泛型会增加实例化、错误信息和 API 复杂度；接口也可能带来分配和动态分派。先根据语义选择，再用基准数据处理性能。

13. API 设计

13.1 接受接口，返回具体类型

这是一条有用但不是绝对的经验：

func Parse(r io.Reader) (*Document, error)

参数只要求最小能力，调用者容易传入不同来源；返回具体类型让调用者看到完整能力，也便于未来增加方法而不破坏已有接口。

如果返回值的核心目的就是隐藏多种实现或建立生命周期边界，返回接口也合理。例如 context.WithCancel 返回 Context 和函数，因为实现细节不应暴露。

13.2 接口通常由消费者定义

// package report
type UserFinder interface {
	FindUser(context.Context, UserID) (User, error)
}

数据库包不必预先声明自己实现 report.UserFinder。这避免生产者创建一个覆盖全部方法的庞大接口，也减轻包间耦合。

被多个消费者共同认可、具有稳定语义的协议接口可以放在生产者或中立包，例如 io.Reader。规则不是“接口绝不能和实现同包”，而是所有权应跟随抽象语义。

13.3 不要预先造接口

只有一个实现且没有实际替换需求时，先公开具体类型。为了“以后可能 mock”给每个结构体配一个同名接口，会增加导航和维护成本。测试可以在真正的消费者处定义最小接口。

13.4 接口演进

给公开接口增加方法是破坏性变更：所有外部实现都会失效。常见替代策略：

• 定义一个嵌入旧接口的新接口；
• 用可选能力接口做探测；
• 增加独立函数；
• 在主版本升级中修改。

删方法也可能影响使用该接口作为约束或嵌入的代码，公开接口变更必须看完整生态。

13.5 上下文和接口

context.Context 通常作为第一个显式参数传递，不应塞进服务结构体，也不应为了省参数把它变成接口方法外的隐藏状态：

Load(ctx context.Context, id ID) (Value, error)

这样取消、超时和请求范围清楚地沿调用链传播。

14. 错误接口

error 是预声明基本接口：

type error interface {
	Error() string
}

任何拥有 Error() string 的类型都实现它。通常自定义错误使用指针接收者：

type NotFoundError struct {
	Resource string
	ID       string
}

func (e *NotFoundError) Error() string {
	return e.Resource + " not found: " + e.ID
}

包装时使用 %w 保留错误链：

return fmt.Errorf("load user: %w", err)

调用方用 errors.Is 判断语义相等，用 errors.As 提取类型。Go 1.26 还增加了泛型 errors.AsType，能以类型安全方式完成常见提取：

if e, ok := errors.AsType[*NotFoundError](err); ok {
	fmt.Println(e.ID)
}

不要依赖 err.Error() 文本判断错误类型。文本面向人，错误链和类型面向程序。

typed nil 在 error 上尤其危险。任何返回具体错误指针的辅助函数，都应确保无错误时返回真正的 nil 接口。

15. 适配、装饰与测试替身

15.1 函数适配接口

单方法接口可以用函数类型适配：

type Handler interface {
	Handle(context.Context, Request) error
}

type HandlerFunc func(context.Context, Request) error

func (f HandlerFunc) Handle(ctx context.Context, r Request) error {
	return f(ctx, r)
}

这让调用者可以直接传闭包，又保留接口组合能力。标准库的 http.HandlerFunc 就是这种模式。

15.2 装饰器

type loggingStore struct {
	next Store
	log  *slog.Logger
}

func (s *loggingStore) Load(ctx context.Context, key string) ([]byte, error) {
	start := time.Now()
	data, err := s.next.Load(ctx, key)
	s.log.InfoContext(ctx, "load", "key", key, "duration", time.Since(start), "err", err)
	return data, err
}

接口适合在稳定协议上叠加日志、指标、重试和鉴权。装饰器仍应尊重上下文取消，且不要吞掉错误或改变并发保证。

15.3 手写测试替身

小接口无需复杂 mocking 框架：

type userFinderFunc func(context.Context, UserID) (User, error)

func (f userFinderFunc) FindUser(ctx context.Context, id UserID) (User, error) {
	return f(ctx, id)
}

测试能直接描述输入和结果，编译器仍检查签名。接口过大时测试替身难写，这本身就是设计反馈。

16. 性能、分配与并发

接口调用通常涉及动态分派，编译器有时能去虚拟化并内联。把具体值装入接口可能导致逃逸，但不是必然；是否分配应通过工具判断：

go test -bench . -benchmem
go test -gcflags=all=-m=2 ./...

性能敏感循环中，[]any 可能带来装箱、类型断言和缓存局部性损失；泛型或具体类型可能更合适。但在 I/O、数据库等高延迟路径中，这点开销通常不是主导因素。

接口值的复制不提供同步。动态值若指向可变对象，多 goroutine 调用是否安全完全由具体实现契约决定。接口文档应说明：

• 方法是否可并发调用；
• Close 能否与其他方法并发；
• 返回的切片或 map 是否由调用方拥有；
• 取消后能否再次使用；
• 实现是否保存回调并异步调用。

接口变量本身被并发读写同样会产生数据竞争。不要认为“换实现只是一条原子引用赋值”；接口概念上包含多部分，竞态下甚至可能观察不一致状态。需要热切换时使用锁或 atomic.Value 并保持存储的具体类型一致。

17. 与 Java 对照

Go 接口	Java 接口	关键差异
隐式实现	implements 显式声明	Go 实现类型无需依赖接口包
方法集结构匹配	名义子类型	Go 签名必须相同，无协变
消费方可定义接口	通常由 API 提供者定义	Go 更容易为现有类型补抽象
接口值	对象引用	Go 要区分 nil 接口与含 nil 指针的接口
接口嵌入	extends interface	都能组合，但 Go 无默认方法状态
约束接口	generic bound	Go 可用 ~T、联合描述类型集合和运算
any	Object	any 是 interface{} 别名，不是类层次根

Java 的 null 对象引用通常只有一层；Go 接口的 typed nil 多了一层动态类型信息。迁移代码时，必须特别检查返回 error 和接口字段的 nil 行为。

18. 常见误区

1. 实现类型必须写声明。 Go 按方法集隐式实现，没有 implements。
2. 能调用指针方法就说明值实现接口。 可取地址的调用改写不参与接口方法集判断。
3. 具体指针为 nil，所以接口等于 nil。 动态类型非空时接口不为 nil。
4. 接口比较永不 panic。 动态值不可比较时，接口相等比较会 panic。
5. any 能提升类型安全。 它通常把错误从编译期推迟到运行时。
6. []T 能转成 []any。 必须逐元素转换。
7. 接口越大越“完整”。 大接口难实现、难测试、难演进。
8. 接口必须由实现方提供。 消费方的小接口通常更解耦。
9. 所有接口都应返回接口。 返回具体类型往往更有用。
10. 约束接口可以声明变量。 含类型项的一般接口只能作为约束。
11. comparable 保证所有接口动态值安全比较。 用接口类型实例化时仍可能遇到动态 panic。
12. 泛型已经取代接口。 泛型解决静态类型关系，接口解决运行时行为抽象。
13. 接口天然并发安全。 安全性由动态实现和使用方式决定。
14. 用字符串匹配 error。 应使用 errors.Is、errors.As 或 Go 1.26 的 errors.AsType。

19. 速查表

需求	写法
声明行为接口	type R interface { Read([]byte) (int, error) }
编译期实现检查	var _ R = (*T)(nil)
安全类型断言	v, ok := x.(T)
必须成功的断言	v := x.(T)
多类型分派	switch v := x.(type) { ... }
组合接口	type RW interface { R; W }
任意值	any
可比较约束	T comparable
底层为整数的一组类型	`interface { ~int
函数适配单方法接口	定义 Func 类型并实现该方法
判断错误链	errors.Is
提取错误类型	errors.As / Go 1.26 errors.AsType
检查竞态	go test -race ./...

接口设计检查：

• 接口是否由真实消费者需求导出？
• 方法是否能再少而不破坏协议？
• nil、所有权、并发和生命周期是否写进文档？
• 添加方法会影响哪些外部实现？
• 这里真正需要运行时多态，还是泛型/具体类型更清楚？

可运行示例

接口常常因为“看起来很灵活”而被过度使用。接下来用最小接口、typed nil 和安全类型断言三个例子，把它真正提供的边界拆开看。

示例一：由使用者定义最小接口

实现关系在哪里建立。 Go 没有 implements。只要类型的方法集满足接口，实现关系就已经成立；实现者与接口声明甚至不必位于同一个包。

package main

import (
	"fmt"
	"strings"
)

type Formatter interface {
	Format(string) string
}

type UpperFormatter struct{}

func (UpperFormatter) Format(input string) string {
	return strings.ToUpper(input)
}

// Render 只依赖自己真正需要的最小接口。
// UpperFormatter 无需声明 implements，方法集匹配就能传入。
func Render(formatter Formatter, input string) string {
	return "[" + formatter.Format(input) + "]"
}

func main() {
	fmt.Println(Render(UpperFormatter{}, "go interface"))
}

运行：

go run ./examples/ch11/implicit-interface

预期输出：

[GO INTERFACE]

这里没有隐藏的注册过程。

1. Render 只要求一个 Format(string) string 方法。
2. UpperFormatter 自然拥有这个方法，不需要依赖接口或登记实现关系。
3. 小接口让测试替身和新实现都更容易加入，也避免实现者被无关方法绑住。

进一步验证。 写一个 PrefixFormatter 满足同一接口并传给 Render；然后给接口增加一个并非 Render 所需的方法，观察已有实现为何会全部失效。

示例二：接口中的 typed nil

先复现 typed nil。 指针明明是 nil，装进接口后 interface == nil 却变成 false。接口值同时保存动态类型与动态值，只有两部分都为空时才等于 nil。

package main

import "fmt"

type Notifier interface {
	Notify() string
}

type EmailNotifier struct {
	Address string
}

func (n *EmailNotifier) Notify() string {
	if n == nil {
		// 方法可以防御 nil receiver，但这只是让示例安全；
		// 更好的 API 通常是不把 typed nil 放进接口。
		return "跳过：没有邮件通知器"
	}
	return "发送到 " + n.Address
}

func main() {
	var email *EmailNotifier
	var notifier Notifier = email

	// 接口由“动态类型 + 动态值”组成。动态类型是 *EmailNotifier，
	// 所以即使动态值为 nil，整个接口也不等于 nil。
	fmt.Println("email == nil:", email == nil)
	fmt.Println("notifier == nil:", notifier == nil)
	fmt.Println(notifier.Notify())
}

运行：

go run ./examples/ch11/typed-nil

预期输出：

email == nil: true
notifier == nil: false
跳过：没有邮件通知器

把接口的两部分分开看。

• email 是值为 nil 的 *EmailNotifier。
• 赋给接口后，动态类型已经是 *EmailNotifier，所以接口本身不为空。
• 方法中的 nil receiver 防御避免本例 panic，但 API 边界最好直接返回真正的 nil 接口。

再看错误写法。 删除 Notify 中的 nil 检查并访问 n.Address，观察 panic 出现在哪一行；再写一个返回 Notifier 的工厂函数，在“没有通知器”时直接 return nil。

示例三：类型 switch 与 comma-ok

断言失败不该终止进程。 面对 any 或第三方接口，直接断言可能 panic。类型 switch 适合多分支分类，value, ok := x.(T) 则适合单次、允许失败的检查。

package main

import "fmt"

func describe(value any) string {
	// 类型 switch 在一次检查中覆盖所有已知动态类型，并保留 default 处理未来扩展。
	switch value := value.(type) {
	case int:
		return fmt.Sprintf("整数的两倍=%d", value*2)
	case string:
		return fmt.Sprintf("字符串长度=%d", len(value))
	case fmt.Stringer:
		return "Stringer=" + value.String()
	default:
		return fmt.Sprintf("未知类型 %T", value)
	}
}

func main() {
	// []any 允许不同动态类型共存，代价是使用前必须显式检查类型。
	values := []any{21, "Go", true}
	for _, value := range values {
		fmt.Println(describe(value))
	}

	raw := any("safe")
	text, ok := raw.(string)
	// comma-ok 避免断言失败时 panic，适合处理外部或不可信动态值。
	fmt.Printf("断言成功=%t value=%q\n", ok, text)
}

运行：

go run ./examples/ch11/type-assertion

预期输出：

整数的两倍=42
字符串长度=2
未知类型 bool
断言成功=true value="safe"

两种检查各有落点。

• switch 每个分支中的 value 已经是相应具体类型，不必再次转换。
• default 保留未知类型的可观测信息，避免静默吞掉扩展值。
• comma-ok 在失败时返回目标类型零值和 false，不会中断进程。

继续增加分支。 增加一个实现 fmt.Stringer 的类型并放入切片；再把 raw 改为整数，确认 text 为空字符串但 ok 为 false，业务判断必须依赖 ok。

20. 练习

1. 定义 Notifier，分别让值和指针实现，使用编译期断言验证方法集。
2. 构造一个返回 typed nil error 的函数，写测试复现，再从 API 源头修复。
3. 编写 Describe(any)，用类型 switch 处理 nil、字符串、数字、fmt.Stringer 和默认分支。
4. 将一个十方法仓储接口按三个消费者拆分，说明哪些方法必须保持在同一事务接口中。
5. 用 HandlerFunc 模式把闭包适配成单方法接口，并加日志装饰器。
6. 分别用 []any 和泛型实现切片映射，基准比较分配和类型安全。
7. 编写 Set[T comparable]，再用 any 实例化并放入切片值，解释为什么运行时仍可能 panic。
8. 为公开接口设计一次“新增能力”演进，不修改旧接口，通过可选接口探测实现。
9. 使用 errors.AsType 提取自定义错误，并保留两层 %w 包装。
10. 写一个并发替换接口实现的示例，先用普通赋值触发 race detector，再用恰当同步修复。

21. 官方资料

• Go 语言规范：Interface types
• Go 语言规范：Method sets
• Go 语言规范：Implementing an interface
• Go 语言规范：Type assertions
• Go 语言规范：Type switches
• Go 语言规范：Comparison operators
• Go 语言规范：General interfaces
• Go 官方泛型教程
• Go 官方博客：The Laws of Reflection
• Go 官方博客：Error handling and Go
• errors 包
• Go 1.26 发布说明