Home

深色模式

Go语言接口 ​

概述 ​

Go 接口的价值不在“终于也有接口了”，而在它把抽象放在了行为而不是继承关系上。一个类型只要实现了某组方法，就可以被当成这个接口使用，不需要显式声明“我实现了谁”。

这带来两个很 Go 的结果：

  • 抽象可以更轻量
  • 接口边界更容易和实际调用方贴合

但与此同时，接口值、nil、方法集、类型断言这些点也特别容易一起绕起来。得把它们拆开看。

接口是什么 ​

接口本质上是一组方法签名：

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

它描述的不是“这个类型属于哪棵继承树”，而是“这个类型是否具备某种行为”。

Go 的接口实现是隐式的 ​

例如：

go
type MyReader struct{}

func (r MyReader) Read(p []byte) (n int, err error) {
    return 0, nil
}

这里不需要再额外写一句“MyReader implements Reader”。只要方法集满足接口要求，它就实现了接口。

接口真正解耦的是依赖方向 ​

例如：

go
func ReadAll(r io.Reader) ([]byte, error) {
    return io.ReadAll(r)
}

这里调用方只依赖 io.Reader 这个行为边界，而不依赖某个具体类型。

这才是接口真正最有价值的地方。它不是为了显得“抽象很多”，而是为了让依赖关系收在真正需要的最小能力上。

接口值本身由两部分组成 ​

一个接口值通常可以理解成两部分：

  • 动态类型
  • 动态值

例如：

go
var r io.Reader
r = os.Stdin

这时接口值 r 里装着：

  • 动态类型：*os.File
  • 动态值：os.Stdin 对应的具体值

nil 接口和“装着 nil 的接口”不是一回事 ​

这是 Go 接口里最经典的坑之一。

例如：

go
var p *bytes.Buffer = nil
var r io.Reader = p

fmt.Println(r == nil) // false

这里 r 不是 nil 接口，因为它已经有动态类型了，只是动态值恰好是 nil。

类型断言是把接口还原成具体类型 ​

go
v, ok := r.(*bytes.Buffer)

这里的意思是：如果接口值里实际装的是 *bytes.Buffer，就把它断言出来。

类型断言常见于两类场景：

  • 需要访问具体类型特有能力
  • 某些底层工具或框架 API 只能先返回接口类型

但一般业务代码里，不应该把“到处做类型断言”当成常态。

type switch 适合分派具体类型 ​

go
switch v := anyValue.(type) {
case int:
    fmt.Println("int", v)
case string:
    fmt.Println("string", v)
default:
    fmt.Println("unknown")
}

它适合做类型分派，但不适合把业务逻辑写成一整棵巨型类型判断树。

interface{} 和 any ​

Go 1.18 之后，any 只是 interface{} 的别名：

go
var x any

它的意义主要是表达更顺口，不是新类型。

小接口通常比大接口更稳 ​

Go 社区里一个很重要的经验是：接口应该尽量贴着实际使用方定义，而且越小越好。

例如：

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

比起先造一个十几个方法的大总管接口，再逼所有实现都去适配，小接口更容易稳定，也更能反映真实依赖。

接口组合是把能力拼起来，不是把层级堆起来 ​

go
type ReadWriter interface {
    io.Reader
    io.Writer
}

这里的重点是能力组合，而不是接口继承层级。

一条够用的判断线 ​

看接口时，按这个顺序想通常比较稳：

  1. 调用方真正依赖的行为最小集合是什么。
  2. 这个抽象是否真的需要接口，而不是具体类型。
  3. 接口值里装的动态类型和动态值分别是什么。
  4. 当前问题是该靠接口抽象解决，还是在滥用断言还原具体类型。

参考 ​