夜雨聆风如果要评选"Go 里最让人困惑的特性"，interface 绝对能进前三。
表面上看很简单——定义一组方法签名，任何实现了这些方法的类型都自动满足这个接口，不需要显式声明。优雅，简洁。
但一旦涉及到 nil、类型断言、空接口这些东西，各种反直觉的行为就开始冒出来了。面试官也特别喜欢在这上面挖坑。
type MyError struct {
Code int
Msg string
}
func (e *MyError) Error() string {
return e.Msg
}
func doSomething() error {
var err *MyError = nil
// 一些逻辑...
return err // 返回了 nil 指针
}
func main() {
err := doSomething()
if err != nil {
fmt.Println("有错误！", err) // 居然进来了！
}
}err 明明是 nil 啊，为什么 err != nil 是 true？
第一次碰到这个问题的时候我盯着屏幕看了半天，一度怀疑是编译器 bug。搞明白原因之后才发现，这是 interface 底层设计的必然结果。
iface 和 eface
Go 的 interface 在底层有两种表示：
eface：空接口 interface{}
type eface struct {
_type *_type // 类型信息
data unsafe.Pointer // 数据指针
} var x interface{} = 42
eface:
┌────────────────────────┐
│ _type ──→ int 的类型信息 │
│ data ──→ 42 的值 │
└────────────────────────┘
var y interface{} = nil
eface:
┌────────────────────────┐
│ _type = nil │
│ data = nil │
└────────────────────────┘空接口就两个指针，16 字节。_type 存类型信息，data 存实际的值（或指向值的指针）。
iface：非空接口
type iface struct {
tab *itab // 接口表（包含类型信息 + 方法表）
data unsafe.Pointer // 数据指针
}
type itab struct {
inter *interfacetype // 接口类型
_type *_type // 具体类型
hash uint32 // 类型哈希（用于快速类型断言）
fun [1]uintptr // 方法表（变长数组）
} var err error = &MyError{Code: 404, Msg: "not found"}
iface:
┌───────────────────┐
│ tab ──→ itab: │
│ │ inter: error 接口信息 │
│ │ _type: *MyError 类型信息 │
│ │ fun: [Error 方法地址] │
│ │
│ data ──→ &MyError{404, "not found"} │
└───────────────────┘itab 里存的是接口方法到具体类型方法的映射。当你通过接口调用方法时，运行时通过 itab 的 fun 表找到实际要调用的函数。
itab 会被缓存，同一个（接口类型, 具体类型）组合只会计算一次。
回头看那个 nil 坑
现在就能解释了。
func doSomething() error {
var err *MyError = nil
return err
}err 是 *MyError 类型的 nil 指针。当它被赋值给 error 接口时：
iface:
┌────────────────────────────────┐
│ tab ──→ itab (error, *MyError) │ ← 不是 nil！
│ data = nil │ ← 数据是 nil
└────────────────────────────────┘interface 的 tab 字段不是 nil（它知道这是个 *MyError 类型），只是 data 是 nil。
而 err != nil 判断的是 interface 整体是否为 nil——只有 tab 和 data 都是 nil 时才为 nil。
// 这样返回才对
func doSomething() error {
var err *MyError = nil
if err == nil {
return nil // 直接返回 nil，不经过类型转换
}
return err
}或者更好的做法：
func doSomething() error {
// 直接用 error 类型的变量
var err error = nil
// ...
return err
}这个坑的本质是：一个具体类型的 nil 值，装进 interface 之后就不是 nil 了。因为 interface 还记住了类型信息。
类型断言
var i interface{} = "hello"
// 类型断言
s := i.(string) // "hello"
n := i.(int) // panic: interface conversion
// 安全的类型断言
s, ok := i.(string) // ok = true
n, ok := i.(int) // ok = false，n = 0类型断言的实现
断言到具体类型时，运行时比较 eface/iface 里存的 _type 和目标类型是否一致。就是个指针比较，很快。
断言到接口类型时，需要检查具体类型是否实现了目标接口的所有方法。这个检查会查 itab 缓存，如果没缓存过才逐个比较方法，然后缓存结果。
var r io.Reader = os.Stdin
// 断言到具体类型：比较 _type 指针
f, ok := r.(*os.File) // 快
// 断言到接口类型：检查方法集
rw, ok := r.(io.ReadWriter) // 需要查方法表type switch
func describe(i interface{}) {
switch v := i.(type) {
case int:
fmt.Println("整数:", v)
case string:
fmt.Println("字符串:", v)
case error:
fmt.Println("错误:", v.Error())
default:
fmt.Printf("其他类型: %T\n", v)
}
}type switch 编译后就是一串类型断言，没有什么黑魔法。但比手写一堆 if v, ok := i.(Type) 整洁得多。
interface 的隐式实现
Go 不需要 implements 关键字。一个类型只要实现了接口要求的所有方法，就自动满足这个接口。
type Writer interface {
Write(p []byte) (n int, err error)
}
// bytes.Buffer 实现了 Write 方法，自动满足 Writer 接口
// 不需要任何显式声明
var w Writer = &bytes.Buffer{}编译器在编译时检查类型是否满足接口。如果不满足会报编译错误。
有一个常见的技巧——编译时检查接口实现：
// 确保 MyHandler 实现了 http.Handler 接口
// 如果没实现，编译报错
var _ http.Handler = (*MyHandler)(nil)这行代码不会执行任何东西，纯粹是让编译器帮你检查。在写公共库的时候很有用，防止改了结构体的方法签名但忘了更新接口实现。
值接收者 vs 指针接收者
这个点跟 interface 直接相关，面试也老问。
type Animal interface {
Speak() string
}
type Dog struct{ Name string }
// 值接收者
func (d Dog) Speak() string {
return d.Name + ": 汪汪"
}
type Cat struct{ Name string }
// 指针接收者
func (c *Cat) Speak() string {
return c.Name + ": 喵喵"
}var a Animal
a = Dog{Name: "旺财"} // OK：值实现了接口，值和指针都能赋给接口
a = &Dog{Name: "旺财"} // OK
a = &Cat{Name: "咪咪"} // OK：指针实现了接口，指针能赋给接口
a = Cat{Name: "咪咪"} // 编译错误！值不能赋给接口规则用一张表说清楚：
值接收者实现 指针接收者实现
值能赋给接口？ ✅ ❌
指针能赋给接口？ ✅ ✅为什么值接收者实现时指针也能用？因为指针可以解引用得到值。
为什么指针接收者实现时值不能用？因为从值获取指针不总是可行的——有些值是不可取地址的（比如 map 的 value、函数返回值）。Go 为了一致性，干脆不允许。
空接口 interface{} 和 any
Go 1.18 加了 any 作为 interface{} 的别名：
// 完全等价
func foo(x interface{}) {}
func foo(x any) {}空接口可以持有任何类型的值，但用的时候要小心：
func add(a, b any) any {
// 这样不行，any 类型不支持 + 操作
// return a + b
// 得做类型断言
switch a := a.(type) {
case int:
return a + b.(int)
case float64:
return a + b.(float64)
default:
panic("unsupported type")
}
}空接口用多了代码会变得到处都是类型断言，不好维护。能用泛型（Go 1.18+）的场景尽量用泛型，类型安全、性能也更好（编译时确定类型，不需要运行时装箱拆箱）。
接口组合
Go 鼓励小接口，然后通过组合构建大接口：
type Reader interface {
Read(p []byte) (n int, err error)
}
type Writer interface {
Write(p []byte) (n int, err error)
}
type ReadWriter interface {
Reader
Writer
}
type ReadWriteCloser interface {
ReadWriter
Close() error
}标准库里到处都是这种模式。io.Reader 只有一个方法，io.ReadWriteCloser 组合了三个接口。
小接口的好处是：实现成本低，组合灵活。你不需要一上来就实现一个有十个方法的大接口，只实现你需要的那个小接口就行。
这也是为什么 Go 社区有句话："接受接口，返回结构体（Accept interfaces, return structs）"。函数参数用小接口，更灵活；返回值用具体类型，更明确。
小结
interface 的核心要点：
- • 底层是 eface（空接口）或 iface（非空接口），都是两个指针，16 字节
- • nil 的坑：具体类型的 nil 值装进 interface 后不等于 nil，因为 type 信息还在
- • 类型断言到具体类型是指针比较，很快；到接口类型要查方法表
- • 值接收者的方法，值和指针都可以赋给接口；指针接收者的方法，只有指针可以
- • 优先用小接口，通过组合构建复杂接口
下一篇聊 Channel 和 select 的底层实现——channel 是怎么做到 goroutine 之间安全通信的。
