接口（interface）是 Go 面向对象与多态的基石，也是「组合优于继承」哲学的直接体现。它没有 Java 的 implements 关键字，而是靠隐式实现把类型和契约解耦。本章从概念一路挖到运行时的 iface/eface/itab 结构，讲清动态派发、类型断言、nil 接口陷阱、空接口装箱开销以及接口设计原则，最后给出高频面试题的完整解答。

1. 接口概念：鸭子类型与面向接口编程

1.1 什么是接口

接口是一组方法签名的集合。任何类型只要实现了接口里声明的全部方法，就自动满足该接口——不需要显式声明「我实现了它」。这就是 Go 的隐式实现（structural typing / duck typing）：

如果它走起来像鸭子、叫起来像鸭子，那它就是鸭子。

package main

import "fmt"

// Speaker 定义一个「会说话」的契约
type Speaker interface {
    Speak() string // 只声明签名，不含实现
}

// Dog 并没有写 implements Speaker，只要方法齐全即自动满足
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 + ": 喵喵" }

func main() {
    // 面向接口编程：函数只依赖 Speaker，不关心具体类型
    animals := []Speaker{Dog{"旺财"}, Cat{"咪咪"}}
    for _, a := range animals {
        fmt.Println(a.Speak()) // 运行期动态派发到具体实现
    }
}

1.2 隐式实现的价值

这带来一个关键好处：接口可以定义在「使用方」而非「提供方」。你能给标准库里的 *os.File 补一个自己的接口，而无需修改 os 包源码。

1.3 小接口原则：io.Reader / io.Writer

Go 标准库推崇小接口——接口越小越通用、越易实现、越易组合。最经典的两个：

// 标准库 io 包（简化）
type Reader interface {
    Read(p []byte) (n int, err error) // 只有一个方法
}

type Writer interface {
    Write(p []byte) (n int, err error) // 只有一个方法
}

正因为只有一个方法，io.Reader 被 *os.File、*bytes.Buffer、net.Conn、strings.Reader、gzip.Reader 等无数类型实现，io.Copy(dst Writer, src Reader) 一个函数就能在文件、网络、内存缓冲之间任意搬运数据。

import (
    "io"
    "os"
    "strings"
)

func demoSmallInterface() {
    // src 是内存字符串，dst 是标准输出，io.Copy 完全不关心具体类型
    src := strings.NewReader("hello, 小接口\n")
    _, _ = io.Copy(os.Stdout, src) // strings.Reader 满足 Reader，*os.File 满足 Writer
}

经验法则：「接受接口，返回结构体」，且接口尽量只含 1~3 个方法。

2. 接口定义与实现

2.1 方法集匹配规则

一个类型能否满足接口，取决于它的**方法集（method set）**是否覆盖接口的全部方法。指针接收者与值接收者的方法集规则如下：

结论：指针接收者定义的方法，只有指针 *T 能满足接口；值 T 不行。

package main

import "fmt"

type Writer interface {
    Write() string
}

type File struct{ name string }

// 指针接收者
func (f *File) Write() string { return "写入 " + f.name }

func main() {
    var w Writer

    // w = File{"a.txt"} // 编译错误：File 未实现 Writer（Write 是指针接收者）
    w = &File{"a.txt"} // ✅ *File 的方法集包含 Write
    fmt.Println(w.Write())
}

原因：值 T 在传递时是副本，对副本取地址无意义，编译器为避免歧义直接禁止值满足含指针方法的接口。

2.2 一个类型实现多个接口

类型的方法集只要分别覆盖多个接口，就同时满足它们，无需任何额外声明：

type Reader interface{ Read() string }
type Closer interface{ Close() error }

type Socket struct{ addr string }

func (s *Socket) Read() string { return "从 " + s.addr + " 读取" }
func (s *Socket) Close() error { return nil }

func useMulti() {
    s := &Socket{"127.0.0.1"}
    var r Reader = s // 同一个实例
    var c Closer = s // 同时满足两个接口
    _ = r
    _ = c
}

2.3 接口组合（嵌入）

接口可以嵌入其他接口，形成更大的契约。标准库的 io.ReadWriteCloser 就是这么拼出来的：

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

// 组合：满足 ReadWriteCloser 等价于同时满足三个小接口
type ReadWriteCloser interface {
    Reader
    Writer
    Closer
}

组合让你用小接口拼装大接口，而实现方仍然只需按小接口逐一实现方法。这是 Go 「组合优于继承」思想在接口层面的落地。

3. 接口底层结构：eface 与 iface

接口在运行时并不是「空」的抽象概念，它是一个**两字宽（two-word）**的结构体。Go 根据接口是否含方法，分成两种底层表示。

3.1 eface：空接口 interface{} / any

空接口没有方法，运行时用 eface 表示（源码 runtime/runtime2.go）：

// runtime 内部结构（示意）
type eface struct {
    _type *_type         // 指向类型元信息
    data  unsafe.Pointer // 指向实际数据（或数据本身，如果能塞进指针）
}

• _type：描述动态类型（大小、对齐、种类 kind、哈希、比较函数等）。
• data：指向堆/栈上的实际值。

3.2 iface：非空接口

带方法的接口用 iface 表示：

type iface struct {
    tab  *itab          // 接口类型 + 动态类型 + 方法表
    data unsafe.Pointer // 指向实际数据
}

3.3 itab 结构：接口与类型的「桥」

itab（interface table）是 iface 的灵魂，缓存了「某个具体类型如何满足某个接口」：

type itab struct {
    inter *interfacetype // 接口自身的类型信息（它要求哪些方法）
    _type *_type         // 具体动态类型信息
    hash  uint32         // _type.hash 的拷贝，用于 type switch 快速比较
    _     [4]byte
    fun   [1]uintptr     // 方法表：变长数组，存具体类型实现方法的入口地址
}

fun 是关键：它是一张函数指针表，按接口方法的顺序存放具体类型对应方法的机器码入口地址。调用 i.Method() 时，运行时直接查 tab.fun[n] 跳转，这就是动态派发。

3.4 ASCII 结构图

非空接口 iface（如 var w io.Writer = &File{}）
┌───────────────┐
│ iface         │
│  ┌──────────┐ │      ┌─────────────────────────────┐
│  │ tab      │─┼────► │ itab                        │
│  └──────────┘ │      │  inter ─► interfacetype     │ 接口要求
│  ┌──────────┐ │      │  _type ─► _type (*File)     │ 动态类型
│  │ data     │─┼──┐   │  hash                       │
│  └──────────┘ │  │   │  fun[0] ─► File.Write entry │ 方法表
└───────────────┘  │   │  fun[1] ─► ...              │
                   │   └─────────────────────────────┘
                   ▼
              ┌─────────┐
              │ File{}  │ 实际数据
              └─────────┘

空接口 eface（如 var x any = 42）
┌───────────────┐
│ eface         │
│  ┌──────────┐ │      ┌──────────────┐
│  │ _type    │─┼────► │ _type (int)  │
│  └──────────┘ │      └──────────────┘
│  ┌──────────┐ │      ┌──────────────┐
│  │ data     │─┼────► │ 42           │ 装箱后的值
│  └──────────┘ │      └──────────────┘
└───────────────┘

核心区别：eface 没有方法表（fun），只需 _type；iface 需要 itab 来存方法表以支持动态派发。

4. itab 的作用与缓存

4.1 动态派发流程

以 w.Write(p) 为例（w 是 io.Writer）：

w.Write(p)
   │
   ├─ 1. 取 w.tab.fun[Write 的索引]  ← 得到具体类型方法入口
   ├─ 2. 把 w.data 作为接收者（receiver）传入
   └─ 3. call 该地址

相比直接调用，多了「查表 + 间接跳转」两步，因此接口调用无法内联，比直接调用略慢（详见第 9 节）。

4.2 itabTable 全局缓存

生成一个 itab 需要遍历接口方法、在具体类型的方法集里查找匹配、填充 fun 表——这是有成本的。Go 运行时用一张全局哈希表 itabTable 缓存已生成的 (interfacetype, _type) 组合：

第一次   var w io.Writer = &File{}
         └─► getitab(inter=io.Writer, typ=*File)
             └─► 查 itabTable：miss
                 └─► 生成 itab、填 fun 表、写入 itabTable

后续     var w2 io.Writer = &File{}
         └─► getitab(...)：hit，直接复用同一个 *itab

• 大多数 (接口, 类型) 组合在编译期就能确定，编译器会把 itab 静态生成到只读段，运行期零开销。
• 只有类型断言、反射等运行期才确定的组合，才走 getitab + itabTable 动态查找/缓存的慢路径。

4.3 hash 字段的用途

itab.hash 是 _type.hash 的副本，专门服务于 type switch：运行时先用 hash 快速筛掉不可能匹配的 case，再做精确类型比较，避免每个 case 都做昂贵的比较。

5. 类型断言（Type Assertion）

类型断言从接口值里「取出」具体类型的值。

5.1 两种写法

package main

import "fmt"

func main() {
    var i any = "hello"

    // 写法一：单返回值，断言失败直接 panic
    s := i.(string)
    fmt.Println(s) // hello

    // 写法二：comma-ok，安全，失败返回零值 + false，不 panic
    n, ok := i.(int)
    fmt.Println(n, ok) // 0 false

    // 生产代码永远优先用 comma-ok 形式
    if v, ok := i.(string); ok {
        fmt.Println("是字符串:", v)
    }
}

5.2 断言失败的 panic

var i any = 42
s := i.(string) // panic: interface conversion: interface {} is int, not string

单返回值形式在类型不匹配时会触发 panic。除非你 100% 确定类型，否则用 comma-ok。

5.3 断言到接口

断言的目标不仅可以是具体类型，也可以是另一个接口——用于探测某个值是否额外满足某接口：

type Stringer interface{ String() string }

func tryString(v any) {
    // 探测 v 是否实现了 Stringer 接口
    if s, ok := v.(Stringer); ok {
        fmt.Println("有 String 方法:", s.String())
    } else {
        fmt.Println("没有 String 方法")
    }
}

fmt 包内部就是这么工作的：打印任意值时先断言 error、再断言 Stringer，命中就调用对应方法。

5.4 断言的性能

• 断言到具体类型：运行时比较 eface._type（或 iface.tab._type）与目标类型指针，是否相等，O(1)，极快。
• 断言到接口：需要 getitab 判断类型是否满足该接口，若缓存命中很快，未命中要构建 itab，稍慢。

// 断言到具体类型：本质是一次指针比较
v, ok := i.(int) // 比较 i 的 _type 是否 == int 的 _type

6. 类型 switch（Type Switch）

当需要对多种可能的类型分别处理时，type switch 比一连串断言更清晰。

6.1 基本用法

package main

import "fmt"

func describe(i any) string {
    switch v := i.(type) { // 注意固定语法 i.(type)，只能用在 switch 里
    case nil:
        return "nil"
    case int:
        return fmt.Sprintf("int: %d", v) // v 在此分支是 int
    case string:
        return fmt.Sprintf("string: %q", v) // v 在此分支是 string
    case bool, float64: // 多类型 case，此时 v 仍是 any（因为无法确定唯一类型）
        return fmt.Sprintf("bool 或 float64: %v", v)
    default:
        return fmt.Sprintf("未知类型: %T", v)
    }
}

func main() {
    fmt.Println(describe(42))      // int: 42
    fmt.Println(describe("go"))    // string: "go"
    fmt.Println(describe(3.14))    // bool 或 float64: 3.14
    fmt.Println(describe(nil))     // nil
    fmt.Println(describe([]int{})) // 未知类型: []int
}

要点：

• v := i.(type) 中的 .(type) 是固定语法，只能出现在 switch 里。
• 单类型 case 中，v 被赋予该具体类型；多类型 case（case A, B）中 v 保持接口类型。
• case nil 匹配接口本身为 nil 的情况。

6.2 原理

type switch 底层不是逐个做类型断言，而是：

1. 取接口的动态类型信息（_type）与其 hash。
2. 用 hash 在各 case 之间做快速哈希比较，缩小候选。
3. 命中候选后做精确的 _type 指针比较确认。

对含大量 case 的 switch，编译器可能生成哈希跳转表，比 if-else 断言链更高效。

7. nil 接口陷阱（重中之重）

这是 Go 面试与线上事故的头号坑。

7.1 接口 == nil 的真正条件

一个接口值等于 nil，当且仅当它的类型指针（_type/tab）和数据指针（data）都为 nil。只要装进了任何具体类型信息，接口就不再是 nil——哪怕那个具体值本身是 nil 指针。

接口值 = (type, data)

interface == nil  ⟺  type == nil  且  data == nil

7.2 经典 bug：返回具体类型的 nil 指针

package main

import "fmt"

type MyError struct{ msg string }

func (e *MyError) Error() string { return e.msg }

// ❌ 有 bug 的写法：返回具体指针类型
func doSomethingBad() error {
    var p *MyError = nil // 具体类型的 nil 指针
    // ... 假设没出错，p 保持 nil
    return p // 把 (*MyError)(nil) 装进 error 接口
}

func main() {
    err := doSomethingBad()
    if err != nil {
        // 竟然进了这里！
        fmt.Println("居然不为 nil！err =", err) // err = <nil> 但 err != nil 成立
    }
    fmt.Printf("类型=%T, 值=%v\n", err, err) // 类型=*main.MyError, 值=<nil>
}

输出：

居然不为 nil！err = <nil>
类型=*main.MyError, 值=<nil>

7.3 图解为什么

返回的接口 err 的内部结构：
┌───────────────────────────┐
│ iface (error)             │
│   tab   ─► itab(*MyError) │  ← type 不为 nil！
│   data  ─► nil            │  ← data 确实是 nil
└───────────────────────────┘

判断 err == nil：
   type == nil ?  ✘ (指向 *MyError 的 itab)
   data == nil ?  ✔
   → 只要 type 不为 nil，整体就 != nil

return p 时，p 是 *MyError 类型，即便值为 nil，装箱进 error 接口后 tab 被填成 *MyError 的 itab，于是 err != nil。

7.4 正确写法

// ✅ 写法一：明确返回 nil 字面量（接口的 nil）
func doGood1() error {
    return nil // type 和 data 都为 nil，才是真正的 nil 接口
}

// ✅ 写法二：出错才赋值，否则直接返回 nil
func doGood2(fail bool) error {
    if fail {
        return &MyError{"出错了"}
    }
    return nil
}

// ⚠️ 若中途用了具体类型变量，返回前务必判空并返回 nil
func doGood3(fail bool) error {
    var p *MyError
    if fail {
        p = &MyError{"出错了"}
    }
    if p == nil {
        return nil // 关键：显式返回接口 nil，而不是 return p
    }
    return p
}

铁律：函数签名用 error（接口）时，绝不要返回具体的错误指针类型变量；要么返回 nil 字面量，要么返回非 nil 的具体错误。

8. 空接口 any

8.1 any 只是 interface{} 的别名

Go 1.18 引入 any 作为 interface{} 的类型别名（不是新类型）：

// builtin 包中
type any = interface{} // 完全等价，可互换

func f1(v interface{}) {}
func f2(v any)         {} // 等价，更简洁

推荐新代码统一用 any，可读性更好。

8.2 装箱与拆箱

把一个具体值赋给空接口叫装箱（boxing），从接口取回叫拆箱（unboxing，即类型断言）：

var x any = 42 // 装箱：把 int 42 塞进 eface
n := x.(int)   // 拆箱：从 eface 取回 int

8.3 逃逸开销

装箱常常导致值逃逸到堆上，因为 eface.data 是指针，必须指向一块能被 GC 追踪的内存：

func boxing() {
    x := 42
    var i any = x // x 可能逃逸到堆（装箱需要一个可被指针引用的地址）
    _ = i
}

用 go build -gcflags='-m' 可以看到类似 x escapes to heap 的提示。

优化点：

• 小整数（Go 对 0~255 的部分小值有 staticuint64s 优化，避免重复分配）。
• 高频路径避免把大量值装箱进 any（如 fmt.Sprintf 的可变参数 ...any 会全部装箱）。

// 热路径中这行会把 3 个值装箱到 []any，产生分配
_ = fmt.Sprintf("%d-%s-%v", id, name, ok)

8.4 泛型出现后的取舍

Go 1.18 引入泛型后，很多原本用 any + 类型断言的场景可以改用类型参数，既保留类型安全又避免装箱：

// ❌ 旧：any 版本，有装箱 + 运行期断言 + 可能 panic
func MaxAny(a, b any) any { /* 需要断言，丑陋且不安全 */ return nil }

// ✅ 新：泛型版本，编译期类型安全，无装箱
func Max[T int | float64 | string](a, b T) T {
    if a > b {
        return a
    }
    return b
}

取舍原则：

9. 接口值比较与动态派发性能

9.1 接口值的比较

两个接口值可用 == 比较，规则：动态类型相同且动态值相等时才相等。

var a any = 10
var b any = 10
fmt.Println(a == b) // true：都是 int 且值相等

var c any = int64(10)
fmt.Println(a == c) // false：类型不同（int vs int64）

⚠️ 陷阱：如果接口内装的是不可比较类型（slice、map、func），用 == 比较会 panic：

var x any = []int{1, 2}
var y any = []int{1, 2}
// fmt.Println(x == y) // panic: comparing uncomparable type []int

9.2 动态派发 vs 直接调用

type Adder interface{ Add(a, b int) int }
type Calc struct{}
func (Calc) Add(a, b int) int { return a + b }

func direct(c Calc, a, b int) int { return c.Add(a, b) }    // 直接调用，可内联
func viaIface(c Adder, a, b int) int { return c.Add(a, b) } // 接口调用，查 itab.fun

性能对比（数量级示意，非精确基准）：

原因：

1. 接口调用需先 tab.fun[n] 取地址再 call，多一次内存访问 + 间接跳转。
2. 编译器无法内联接口方法（运行期才知道具体实现），也就失去了内联带来的进一步优化（常量折叠、逃逸消除等）。

优化建议：

• 绝大多数业务代码，接口调用开销可忽略，优先保证抽象清晰。
• 只有在极热的内层循环（每秒亿级调用）里，才考虑用具体类型或泛型消除动态派发。

// 基准测试骨架，实测你自己的场景再决定是否优化
func BenchmarkIface(b *testing.B) {
    var a Adder = Calc{}
    for i := 0; i < b.N; i++ {
        _ = a.Add(1, 2)
    }
}

10. 接口设计最佳实践

10.1 接受接口，返回结构体

函数参数用接口（灵活、可测试、可 mock），返回值用具体类型（调用方拿到完整能力，不被过早窄化）：

// ✅ 参数接口：任何 Reader 都能传进来
func Parse(r io.Reader) (*Config, error) { /* ... */ return &Config{}, nil }

type Config struct{ /* ... */ }

// ❌ 反例：返回接口，调用方拿不到 *Config 的其他方法/字段
// func Parse(r io.Reader) (SomeInterface, error)

10.2 小接口原则

接口越小越好用。需要多个能力时用组合，而不是定义一个大而全的胖接口：

// ✅ 小接口 + 组合
type Reader interface{ Read(p []byte) (int, error) }
type Writer interface{ Write(p []byte) (int, error) }
type ReadWriter interface { Reader; Writer }

// ❌ 胖接口：实现者被迫实现一堆用不到的方法
type FatService interface {
    Read(); Write(); Close(); Flush(); Seek(); Sync(); Stat() // 太多了
}

10.3 避免过度抽象

不要为了「以后可能扩展」而预先造接口。 Go 社区共识：先写具体类型，等出现第二个实现或明确的测试需要时，再提取接口。过早抽象会带来无谓的间接层和阅读负担。

YAGNI 原则：You Aren't Gonna Need It
只有一个实现 → 不需要接口

10.4 依赖倒置（DIP）

高层模块不应依赖低层模块的具体实现，二者都依赖抽象（接口）。且接口应定义在**使用方（高层）**包中：

package service // 高层：定义它需要什么

// service 定义自己需要的存储契约（小接口）
type UserStore interface {
    GetUser(id int) (*User, error)
}

type UserService struct {
    store UserStore // 依赖抽象，不依赖 mysql/redis 具体实现
}

func (s *UserService) Profile(id int) (*User, error) {
    return s.store.GetUser(id) // 运行期注入任意实现
}

type User struct{ ID int }

package mysql // 低层：提供实现，不需要知道 service.UserStore 的存在（隐式满足）

type Store struct{ /* db 连接 */ }

func (s *Store) GetUser(id int) (*service.User, error) { /* ... */ return &service.User{ID: id}, nil }

这样测试时可以轻松注入内存版 mock：

type fakeStore struct{}
func (fakeStore) GetUser(id int) (*service.User, error) { return &service.User{ID: id}, nil }

// 测试中：svc := &service.UserService{store: fakeStore{}}

11. 高频面试题

Q1：iface 和 eface 有什么区别？

• eface 表示空接口 interface{}/any，只有两个字段：_type（动态类型信息）和 data（数据指针）。没有方法表。
• iface 表示非空接口（带方法），字段是 tab（*itab）和 data。itab 里含 inter（接口类型）、_type（动态类型）、hash 和 fun（方法表）。
• 一句话：eface 不需要方法表，iface 需要用 itab 存方法表来支持动态派发。

Q2：接口 nil 判断的经典 bug 是什么？如何避免？

接口值等于 nil 的条件是 type 和 data 都为 nil。若函数返回类型是接口 error，但你 return 了一个值为 nil 的具体指针类型（如 (*MyError)(nil)），则接口的 type 字段被填成 *MyError，导致 err != nil 成立，出现「明明是 nil 却判断为非 nil」的 bug。

避免：签名用接口时，要么 return nil 字面量，要么返回非 nil 的具体错误；绝不 return p（p 是可能为 nil 的具体指针）。

Q3：类型断言和 type switch 有什么区别？各自适用场景？

• 类型断言 v, ok := i.(T)：判断/取出单个目标类型，优先用 comma-ok 形式避免 panic。
• type switch switch v := i.(type)：对多个可能类型分别处理，更清晰，底层用 hash 加速比较。
• 单类型 case 中 v 是具体类型；多类型 case（case A, B）中 v 仍是接口类型。
• 只判断一种类型用断言；分派多种类型用 type switch。

Q4：接口底层是如何实现多态的？

通过 itab.fun 方法表 + 动态派发：调用 i.Method() 时，运行时从 i.tab.fun[方法索引] 取出该具体类型对应方法的机器码入口地址，把 i.data 作为接收者传入并 call。不同具体类型的 itab 里 fun 指向不同实现，从而同一接口调用表现出不同行为，这就是多态。方法表在编译期或首次使用时构建，并由全局 itabTable 缓存复用。

Q5：空接口装箱有什么开销？

把具体值赋给 any 会装箱：需要一个 _type 指针和一个指向数据的 data 指针，值往往因此逃逸到堆并产生 GC 压力。热点路径（如 fmt.Sprintf 的 ...any、map[string]any）大量装箱会拖慢性能。Go 对部分小整数有 staticuint64s 缓存优化。类型集合已知时应优先用泛型替代 any，避免装箱与运行期断言。

Q6：itab 是什么？它被缓存在哪里？

itab（interface table）记录「某个具体类型如何满足某个接口」，含 inter（接口类型）、_type（动态类型）、hash（供 type switch 加速）和 fun（方法入口表）。大多数 (接口, 类型) 组合在编译期就生成好静态 itab；运行期才确定的组合（断言、反射）通过 getitab 生成，并缓存到全局哈希表 itabTable，下次同组合直接复用，避免重复构建。

Q7：为什么值接收者的方法能满足接口，指针接收者不行（反之可以）？

方法集规则：值 T 的方法集只含值接收者方法；指针 *T 的方法集含值接收者 + 指针接收者方法。因为指针接收者方法会修改接收者，若允许一个不可寻址的值副本满足接口，修改将丢失且语义不清，编译器直接禁止。所以「指针接收者方法只有 *T 能满足接口」。

Q8：接口调用比直接调用慢多少？为什么？

慢在两点：一是多一次「查 tab.fun 表 + 间接跳转」的内存访问；二是编译器无法内联接口调用（运行期才知道实现），失去内联衍生的优化。相对开销通常在 1.5x 到数倍量级，但绝对值极小（纳秒级）。除非在亿级/秒的热循环里，否则不必为此牺牲抽象；真要优化可用具体类型或泛型。

小结

• 接口是 Go 多态与解耦的核心，采用隐式实现（鸭子类型）：方法齐全即满足，接口可定义在使用方。
• 小接口原则（io.Reader/io.Writer）+ 接口组合嵌入让抽象既通用又可拼装。
• 方法集规则决定谁能满足接口：指针接收者方法只有 *T 满足。
• 底层：空接口用 eface(_type, data)，非空接口用 iface(tab, data)；itab 含接口类型、动态类型、hash 和 方法表 fun，是动态派发的关键，并由 itabTable 全局缓存。
• 类型断言优先用 comma-ok 防 panic；type switch 用 hash 加速多类型分派。
• nil 接口陷阱：接口 == nil 需要 type 与 data 都为 nil；返回具体 nil 指针给 error 会踩坑——签名是接口就 return nil 字面量。
• 空接口 any（interface{} 别名）会装箱、易逃逸；类型集合已知时改用泛型更安全更快。
• 设计上遵循「接受接口、返回结构体」「小接口」「避免过度抽象」「依赖倒置」。

掌握 iface/eface/itab 的结构，你就能一眼看穿动态派发、nil 陷阱和装箱开销的本质——这正是接口相关面试题的底层答案。