Go 的接口是纯方法集，没有 implements，方法集覆盖就自动满足。这份自由有两个代价："谁实现了这个接口"无法靠搜索定位；接口值在运行时是类型指针 + 数据指针两部分，任一部分为 nil 都让"接口等不等于 nil"变得反直觉。这篇从隐式实现讲到 iface 表示、nil 双关坑、类型断言与 errors.As，最后落到"接口该在哪定义"。

---

1. 接口是方法集，隐式实现

type Speaker interface{ Speak() string }

type Dog struct{ Name string }

func (d Dog) Speak() string { return d.Name + ": wang" }   // 值接收者

type Robot struct{ ID int }

func (r *Robot) Speak() string { return fmt.Sprintf("unit-%d", r.ID) } // 指针接收者

var a Speaker = Dog{"d1"}      // OK：值满足
var b Speaker = &Robot{ID: 7}   // OK：必须取址
// var c Speaker = Robot{ID: 7} // 编译错误：方法集不含指针接收者方法

维度	Go	Java
实现声明	隐式，方法集自动满足	显式 implements
接口位置	任何包都能定义	通常由实现方或框架提供
接口大小	常见 1–2 个方法	常见 5–20 个方法
空接口	any（interface{}）	Object
默认方法	无	default 方法
能否有字段	不能	不能（除常量）

直接好处：你可以在自己的包里为别人的类型定义接口，不需对方配合。io.Reader 能被任何有 Read([]byte) (int, error) 方法的类型满足。代价是 go doc 不告诉你谁实现了它，重构接口时只能靠编译器逐个报错。

1.1 编译期实现断言

var _ io.Writer = (*Buf)(nil)   // 编译期检查 *Buf 是否实现 io.Writer

_ 加类型断言在包级声明，编译不过就直接失败，比运行时才发现要好。这是库里非常常见的写法。

---

2. 接口的底层表示

接口值不是一个指针，是两个字：

type iface struct {   // 带方法的接口
	tab  *itab        // 类型信息 + 方法表
	data unsafe.Pointer
}

type eface struct {   // 空接口 any
	_type *_type
	data  unsafe.Pointer
}

情形	tab/_type	data	接口值 == nil
var s Speaker	nil	nil	true
var p *Dog; var s Speaker = p	有（*Dog 类型）	nil	false
var s Speaker = Dog{}	有	非 nil	false
var a any = nil	nil	nil	true

关键点：接口为 nil 的判据是两个字段都为 nil。第二行是经典坑——把一个 nil 指针赋给接口，接口本身不为 nil。

---

3. 接口值为 nil 的两种情形

type Speaker interface{ Speak() string }
type Dog struct{ Name string }

func (d *Dog) Speak() string {
	if d == nil {
		return "nil dog"   // 关键：指针接收者内先判空
	}
	return d.Name
}

var d *Dog
var s Speaker = d
d == nil          // true
s == nil          // false！接口持有 (*Dog, nil)
s.Speak()         // "nil dog"，安全

var s2 Speaker
s2 == nil          // true，真正的 nil 接口
// s2.Speak()      // panic: nil pointer dereference

判断	结果	原因
d == nil	true	指针本身为空
s == nil	false	类型字段非空，数据字段为空
s.Speak()	取决于方法实现	指针接收者方法不解引用就安全
s2.Speak()	panic	接口无方法表，无派发目标

这是 Go 里最常见的"判空失败"来源：函数返回 *T，调用方把它塞进接口再判 == nil，永远为 false。

修法有两种：

// 1. 返回接口而不是具体指针，让 nil 语义在返回点就统一
func get() Speaker {
	var d *Dog
	if d == nil {
		return nil        // 显式返回 nil 接口
	}
	return d
}

// 2. 保持返回 *T，调用方判空再装箱
d := getDog()
if d != nil {
	var s Speaker = d
	_ = s
}

原则：不要在"返回具体指针"和"存进接口"之间来回穿越。要么全程指针 + 判空，要么全程接口 + nil 接口。

---

4. 类型断言与类型 switch

var a any = "hello"

s, ok := a.(string)   // hello true
n, ok := a.(int)      // 0 false，二值形式不 panic
// s2 := a.(int)      // 单值形式：panic: interface conversion

形式	失败行为	适用
v, ok := x.(T)	v 为零值，ok=false	绝大多数场景
v := x.(T)	panic	已确定类型，或 panic 可接受
x.(type)	仅限 switch 语句	多类型分支

类型 switch 的写法与默认分支：

func describe(x any) string {
	switch v := x.(type) {
	case nil:
		return "nil"
	case int, int64:
		return "整数"
	case string:
		return "字符串长度 " + strconv.Itoa(len(v))
	case error:
		return "错误: " + v.Error()
	default:
		return fmt.Sprintf("未知类型 %T", v)
	}
}

注意 case int, int64: 这种多类型分支里，v 的类型是 any（因为分支不唯一），不能直接用 v + 1；单类型分支里 v 才是具体类型。

断言目标	成功条件
具体类型 T	动态类型恰为 T
接口 I	动态类型的方法集满足 I
nil	仅 switch 的 case nil

断言到接口是很多人忽略的能力：x.(io.Reader) 判断的不是类型相等，而是方法集满足。

---

5. 接口组合与小接口哲学

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

type ReadWriter interface {
	Reader
	Writer
}

type ReadWriteCloser interface {
	Reader
	Writer
	io.Closer
}

嵌入接口就是方法集的并集。标准库的设计哲学是一条：接口越小越有用。

接口	方法数	为什么好用
io.Reader	1	任何字节源都能满足，测试里用 strings.NewReader 就够
io.Writer	1	日志、缓冲、网络统一抽象
fmt.Stringer	1	自动被 Println 使用
error	1	整个错误体系的基础
http.Handler	1	中间件可无限套

单方法接口的好处是可组合性：io.Copy(dst Writer, src Reader) 不关心两端是什么，只要能读写。定义 5 个方法的接口，能满足它的类型就少一个数量级。

---

6. 接口该在哪定义

Go 的惯例是消费方定义接口，不是实现方提前抽象。

// 差：实现包的 Store 有 5 个方法，调用方几乎只用到 1 个
type Store interface {
	Get(id string) (*User, error)
	Put(u *User) error
	List() ([]*User, error)
	Delete(id string) error
	Close() error
}

// 好：消费方只声明自己用得到的那一小块
type userGetter interface{ Get(id string) (*User, error) }

位置	谁定义	好处	代价
实现方定义	库作者	调用方拿到统一抽象	接口容易过大，逼迫过度抽象
消费方定义	调用方	只声明需要的，天然最小	同一能力可能被多处重复声明
标准库定义	语言作者	生态通用	无法覆盖所有场景

判断标准：接口的每个方法是否都被调用方用到。有一个方法从没被调用，它就不该在这个接口里。

---

7. 接口对性能的影响

接口调用是动态派发，比直接调用多一次方法表查找；接口赋值可能触发装箱（值复制到堆）。

var x any = 42        // 装箱：值复制进堆，eface 持有指针

操作	开销	说明
接口赋值（大结构体）	复制 + 可能堆分配	值被搬进堆
接口方法调用	一次间接跳转	现代 CPU 分支预测友好时接近直接调用
类型断言	一次类型比较	断言到接口需遍历方法集
传 any 给 fmt.Println	装箱 + 反射	热路径里应避免

工程结论：热路径避免 any。序列化、日志、缓存 key 都容易踩；把 fmt.Sprintf 换成 strconv 是常见优化点，收益按基准测试核对。

---

8. errors.Is / errors.As 与接口

var ErrNotFound = errors.New("not found")

type QueryError struct {
	SQL string
	Err error
}

func (e *QueryError) Error() string { return "query failed: " + e.SQL }
func (e *QueryError) Unwrap() error { return e.Err }

err := &QueryError{SQL: "select 1", Err: ErrNotFound}
errors.Is(err, ErrNotFound)   // true，沿 Unwrap 链匹配哨兵

var qe *QueryError
errors.As(err, &qe)           // true，沿链逐层类型断言

函数	匹配方式	目标参数
errors.Is(err, target)	沿 Unwrap 链逐层 == 比较	哨兵错误值
errors.As(err, &target)	沿链逐层类型断言	目标类型的指针的指针
errors.Unwrap(err)	取下一层	—

As 的第二个参数必须是指针的指针，因为要把匹配到的值写回去。传 &qe 而非 qe 是必须的。

errors.As 内部是类型断言加链遍历，所以第 3 节的 nil 接口坑在这里同样成立：若某层 Unwrap() 返回"持有 nil 指针的接口"，As 匹配成功但 qe 为 nil。

---

9. 排错：五个高频坑

现象	原因	处理
函数返回 nil 但 err != nil 成立	返回了持有 nil 指针的接口	返回点显式 return nil
cannot use t (type T) as type I	实现方法在 *T 上	传 &t 或改值接收者
panic: interface conversion	单值断言失败	改用 v, ok 形式
errors.Is 一直 false	用了 %v 而非 %w	见 X06
接口方法从没被调用	接口定义过大	按消费方需要裁剪

---

10. 边界：这些情况本就该用别的方案

场景	用接口	更合适的选择
只有一个实现	提前抽接口	直接用具体类型，需要时再抽
需要存多种类型的集合	[]any	泛型 []T（Go 1.18+）
需要类型无关的算法	any + 断言	泛型 + 类型约束
需要区分"未设置"	接口 + 判空	*T 或 Optional[T]
需要跨包插件	接口	接口 + 显式注册表，别靠 init() 隐式注册

泛型出现后，"为复用而抽接口"的必要性下降不少。能用类型参数表达的约束就不必用接口；接口更适合表达"行为"而非"类型集合"。

---

11. 自测

1. 一个 *T 为 nil 的指针赋给接口后，接口 == nil 的结果是什么？为什么？
2. 只有指针接收者方法的类型，它的值能赋给接口吗？
3. x.(io.Reader) 判断的是类型相等还是方法集满足？
4. errors.As(err, &target) 的第二个参数为什么必须是指针的指针？
5. 为什么标准库的接口大多只有 1 个方法？这对可测试性有什么影响？
6. 接口惯例上应该由实现方还是消费方定义？判据是什么？