《Go 接口与泛型：隐式实现到类型参数》

要做什么，不做什么

把 Go 类型系统里最容易被混着讲的两块拆开讲透：接口的隐式满足（含接口值内部结构和那个经典的 nil 坑）与泛型的类型参数（语法、约束、边界），最后给一套”这段代码该用接口还是泛型”的判断。边界先说死：不抠运行时 iface/itab 的内存布局，知道接口值是个二元结构就够用；不比泛型与反射的性能（公开口径下泛型通常更快，但拿性能当设计依据是本末倒置）；不涉及代码生成。版本口径：Go 1.22（2024-02-06 GA）；泛型自 Go 1.18（2022-03 GA）引入，到本版语法两年半没动过——放心学。

接口：方法集的隐式契约

Go 的接口没有 implements 关键字：一个类型把接口要求的方法全实现了，它就自动满足这个接口。声明方定义契约，实现方不需要登记——这让”给既有类型补抽象”零成本：io.Reader、fmt.Stringer 定义在那里，新类型天生就能接入。

type Notifier interface {
    Notify(msg string) error
}

// Mailer 没写一个字说"我实现了 Notifier"，但它就是
type Mailer struct{ Addr string }

func (m Mailer) Notify(msg string) error {
    // 发邮件……
    return nil
}

隐式满足的实战价值在依赖注入：业务代码只依赖 Notifier，测试里塞一个假实现，生产里塞 Mailer，双方互不知道对方存在。还有一条容易被忽略的习惯：接口定义放使用方那一侧，而不是实现方——”我需要什么”由消费者声明。这是 Go 和 Java 系最大的习惯差异，也是隐式实现才养得起的习惯。

接口值里面装着什么

接口变量不是指针也不是普通值，是（动态类型, 动态值）二元组。所有 nil 相关的经典坑都从这来：

var w io.Writer          // (nil, nil)，此时 w == nil 为 true
var b *bytes.Buffer = nil
w = b                    // 装进了 (*bytes.Buffer, nil)

fmt.Println(w == nil)    // false！动态类型不空就不算 nil
w.Write([]byte("hi"))    // panic：nil 接收器解引用

修法不在接口侧，在返回错误的地方：函数返回 error 时别写 var e *MyError = nil; return e，直接 return nil。看懂了二元组，这类 bug 十秒定位；看不懂，能查一天。

类型断言与 type switch 是对二元组的直接操作：v, ok := w.(*bytes.Buffer) 问”动态类型是不是它”，switch 问”在候选里是哪个”。能用接口方法表达的就别断言具体类型——每断言一处，抽象就漏一处。

泛型：类型参数与约束

接口解决”异构多态”，泛型解决”同构复用”：同一段逻辑作用于不同类型，又不想用 any 加类型断言把检查推迟到运行时。

func Min[T int | float64 | string](a, b T) T {
    if a < b {
        return a
    }
    return b
}

Min(3, 5)               // T 推断为 int
Min("a", "b")           // T 推断为 string
Min[float64](3, 5.0)    // 混合字面量时显式指定

方括号里的 T 是类型参数，| 连起来的类型集合就是约束——T 必须落在集合里，且支持的操作（这里是 <）集合里每个类型都得有。约束本身就是接口的扩展形态，写成命名接口更常用：

// ~ 表示"以该类型为底层类型的都算"：type MyInt int 也匹配
type Number interface {
    ~int | ~int64 | ~float64
}

func Sum[T Number](xs []T) T {
    var total T
    for _, x := range xs {
        total += x
    }
    return total
}

// comparable 是预置约束：支持 == 的类型，map 的 key 必须满足
func Keys[K comparable, V any](m map[K]V) []K {
    keys := make([]K, 0, len(m))
    for k := range m {
        keys = append(keys, k)
    }
    return keys
}

~ 这个符号值得单独说：没有它，int | float64 只认这两个类型本尊，type MyInt int 不匹配；带上 ~，底层类型一致的自定义类型一起收进来。约束里也能放方法——interface { Key() string } 作为约束时，T 必须实现该方法，这就是”接口当约束”的常态。手写约束之前先翻标准库：Go 1.21 起 slices、maps 两个泛型包覆盖了大部分容器工具需求，别重复造轮子。

约束也是隐式满足的

标题里两个词在这点上汇合：泛型约束延续了接口的隐式哲学。结构约束（类型集合）看底层类型，方法约束看方法集，实现方都不用登记。一个类型满足约束不需要任何声明动作，编译器在实例化那一刻对照检查——语义和接口的”用到才知道满不满足”一脉相承。

把语法攒成一个容器：泛型栈

二十行的泛型栈，把要点全带出来：

type Stack[T any] struct {
    items []T
}

func (s *Stack[T]) Push(v T) { s.items = append(s.items, v) }

func (s *Stack[T]) Pop() (T, bool) {
    var zero T
    if len(s.items) == 0 {
        return zero, false // 泛型零值没有统一字面量，var zero T 是标准姿势
    }
    v := s.items[len(s.items)-1]
    s.items = s.items[:len(s.items)-1]
    return v, true
}

两个语法点：方法接收器写作 *Stack[T]，类型参数跟类型名走；方法自己不能再添类型参数——”泛型方法”在当前语言里不存在，想加参数只能挪到类型上或写成独立函数。零值处理用 var zero T，因为 T 可能是 int 也可能是 string，没有统一写法。

验收就一条：var s Stack[string]; s.Push("a"); v, ok := s.Pop() 编译通过且 v 的类型是 string——全程没有断言，IDE 的补全和跳转全程在线。这是泛型对 any 的核心胜利：类型信息在编译期活着。

何时接口，何时泛型

两者都提供抽象，方向相反。我的判断一句话：处理”不同的东西”用接口，处理”相同逻辑套不同类型”用泛型。

• 用接口：行为抽象与多态。依赖注入、插件注册、策略替换——手里有一批”长得不一样、但会同一件事”的东西。测试替身（mock）也建立在接口上，这是它的常态用法。
• 用泛型：容器与算法。栈、队列、缓存、Sum/Min、map 工具——逻辑与元素类型完全无关。动手前问一句”元素类型参与过这段逻辑吗”，没参与就该泛型。
• 两个都别用：逻辑真的只有一种类型时。为想象中的重用提前泛型化是过度设计；只有一个实现的接口同样值得怀疑——除非它生来就是为了解耦依赖、给测试留门。

站内的《用 Go 写一个并发安全的内存缓存》结尾留了作业：把 map[string]*entry 泛型化成 Cache[K comparable, V any]。现在你有语法底子了——Key 换成 K、Value 换成 V，entry 里存 V，Get 返回 (V, bool)，编译器会在每个调用点替你检查类型。改完 go test -race 全绿，这份作业就算交了。

同一个需求的两副面孔

把判断落到代码上，对照着看最清楚：

// 接口版：抽象的是"行为"，背后站着长得不同的实现
type Sender interface {
    Send(to string, body []byte) error
}

// 泛型版：抽象的是"元素类型"，循环体对所有类型一字不差
func Contains[T comparable](xs []T, want T) bool {
    for _, x := range xs {
        if x == want {
            return true
        }
    }
    return false
}

Sender 背后站着邮件、短信、推送三种实现，它们的 Send 各干各的事——接口的地盘；Contains 对 int 和 string 执行完全相同的循环——泛型的地盘。标准库自己的演变也是这条判断的注脚：排序从 sort.Interface（接口加方法集，Len/Less/Swap 三件套）演进到 slices.SortFunc（泛型加比较函数），前者留给需要按多个字段、带状态的复杂排序，后者接管了”给一个切片排个序”的日常。API 在换代，判断标准没变：行为分叉用接口，类型参数化用泛型。

三个容易踩的坑

• 接口零值不等于空指针。前面 typed-nil 那段占了接口 bug 的一半以上，返错误的函数统一 return nil。
• 泛型函数里要对 T 做类型分叉。T 不能直接 type switch，先转 any：switch v := any(x).(type)。但先想清楚——需要按类型分叉的逻辑多半不该泛型化，退回接口或者拆函数。
• 约束越写越大。类型集合从三五个类型膨胀到覆盖半个标准库时，该停手退回接口。约束是给编译器的合同，不是类型穷举游戏。

验收清单

• typed-nil 案例亲手跑一遍：输出 false，且能口头解释二元组原因；
• Stack[T] 编译通过，空栈 Pop 返回 (zero, false)，零值语义正确；
• Sum 对 int 与 float64 各跑一次结果正确；定义 type MyInt int 后接 ~ 约束能编译，去掉 ~ 编译失败——~ 的作用亲手验证过；
• Keys 对含切片字段的自定义 struct key 编译拒绝，换成全可比字段后通过——comparable 的边界；
• 缓存作业：Cache[K, V] 改造完成，go test -race 全绿。

学完之后

接口与泛型不是二选一，工程里常见的形态是里外两层：对外用接口定行为边界，接口内部的通用逻辑用泛型压缩重复。并发的部分——goroutine 与 channel 如何和这两种抽象组合——《Go 并发基础》有对应的底子；想把 Cache[K, V] 的改造走完整流程（含并发验收），回《用 Go 写一个并发安全的内存缓存》照着做即可。

本文数据核对时间：2024-07-22：Go 1.22（2024-02-06 GA）；泛型语法由 Go 1.18（2022-03 GA）引入，本文口径下无语法变动；slices、maps 泛型标准库包自 Go 1.21 起可用；接口值（动态类型, 动态值）与 typed-nil 行为以 go.dev/ref/spec 及 Go FAQ 为准。