一、为什么需要 Go 泛型
Go 泛型（Go generics）自 1.18 引入后，让我们可以用类型参数编写类型安全的通用代码，彻底告别 interface{} 的装箱、拆箱与类型断言。在没有泛型的年代，想写一个“返回两数中较大值”的函数，要么为 int、float64、string 各写一份，要么退化成 interface{} 并在运行时断言——前者重复，后者丢失编译期类型安全。本文用可运行的示例，讲清类型参数、约束（constraint）与自定义泛型函数的工程写法。
下面这段代码就是泛型出现前的典型痛点：用 interface{} 实现的“通用”版本，调用方拿到的还是 interface{}，每次都要断言，且无法在编译期发现类型错误。
// 泛型之前：用 interface{}，类型安全在编译期丢失
func MaxOld(a, b interface{}) interface{} {
// 必须运行时断言，且无法约束 a、b 可比较
af, ok1 := a.(float64)
bf, ok2 := b.(float64)
if !ok1 || !ok2 {
panic("only float64 supported")
}
if af >= bf {
return a
}
return b
}
二、类型参数与基础语法
泛型函数使用方括号声明类型参数，紧跟在函数名之后、参数列表之前。T 是一个类型形参（type parameter），在调用时由实参推导，也可以显式指定。
// 泛型函数：类型参数 T 带约束 constraints.Ordered
func Max[T constraints.Ordered](a, b T) T {
if a >= b {
return a
}
return b
}
func main() {
fmt.Println(Max(3, 7)) // 7，T 推导为 int
fmt.Println(Max(1.2, 0.8)) // 1.2，T 推导为 float64
fmt.Println(Max("go", "rust")) // "rust"，T 推导为 string
fmt.Println(Max[int](3, 7)) // 显式指定 T = int
}
2.1 泛型类型
除了函数，类型（struct、slice、map）也可以带类型参数。下面是一个简单的泛型栈，入栈、出栈都保持类型安全。
// 泛型类型：类型安全的栈
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
}
v := s.items[len(s.items)-1]
s.items = s.items[:len(s.items)-1]
return v, true
}
三、类型约束（constraint）
约束决定了类型参数能接受哪些实参，本质是“一个接口，其方法集描述了对类型的需求”。标准库 constraints 包（也可直接写 ~int | ~int64 | ~float64 等）提供了 Ordered、Integer、Float 等常用约束。
3.1 自定义约束
// 自定义约束：只接受数值类型
type Number interface {
~int | ~int64 | ~float64 | ~float32
}
func Sum[T Number](nums []T) T {
var total T
for _, n := range nums {
total += n
}
return total
}
3.2 理解 ~T 底层类型
~int 表示“底层类型是 int 的任意类型”，因此你基于 int 定义的 type UserID int 也能满足约束；如果只写 int 而不加 ~，自定义类型反而会被拒。这是泛型约束里最容易踩坑的细节。
type UserID int
func IDs() []UserID {
return []UserID{1, 2, 3}
}
// Sum[UserID] 能通过，正是因为约束用了 ~int
fmt.Println(Sum(IDs())) // 6
四、泛型与接口的区别
很多人混淆泛型与接口：接口在运行时通过方法集做动态分发，泛型在编译期为每个实参类型生成（或单态化）专用代码。需要“异构集合、行为多态”用接口；需要“同构数据、零开销类型安全”用泛型。
| 维度 | 泛型（generics） | 接口（interface） |
|---|---|---|
| 类型检查时机 | 编译期 | 运行期（方法集） |
| 类型安全 | 强，错误在编译暴露 | 弱，断言失败在运行时 |
| 性能 | 无装箱，零开销 | 有装箱与动态分发 |
| 典型用途 | 容器、算法、工具函数 | 多态行为、插件式实现 |
五、实战：泛型 Slice 工具函数
泛型最适合批量处理同构数据的工具函数。下面用一份泛型实现 Map / Filter / Reduce，可复用于任意切片类型，无需为每种类型重写。
func Map[T, U any](src []T, f func(T) U) []U {
out := make([]U, len(src))
for i, v := range src {
out[i] = f(v)
}
return out
}
func Filter[T any](src []T, pred func(T) bool) []T {
var out []T
for _, v := range src {
if pred(v) {
out = append(out, v)
}
}
return out
}
func main() {
nums := []int{1, 2, 3, 4, 5}
doubled := Map(nums, func(n int) int { return n * 2 }) // [2 4 6 8 10]
evens := Filter(nums, func(n int) bool { return n%2 == 0 }) // [2 4]
fmt.Println(doubled, evens)
}
六、实战：泛型缓存仓储
在多模型项目里，常需要为不同实体做内存缓存。用泛型可以把“存取逻辑”一次写好，实体类型由调用方决定，既避免重复又保留类型安全。
type Cache[K comparable, V any] struct {
store map[K]V
mu sync.RWMutex
}
func NewCache[K comparable, V any]() *Cache[K, V] {
return &Cache[K, V]{store: make(map[K]V)}
}
func (c *Cache[K, V]) Set(k K, v V) {
c.mu.Lock()
defer c.mu.Unlock()
c.store[k] = v
}
func (c *Cache[K, V]) Get(k K) (V, bool) {
c.mu.RLock()
defer c.mu.RUnlock()
v, ok := c.store[k]
return v, ok
}
七、标准库里的泛型：slices 与 maps 包
从 Go 1.21 起，标准库新增了 slices 与 maps 两个泛型包，把过去需要手写的排序、去重、包含判断等逻辑一并收编。它们全部用泛型实现，适用于任意可比较或有序的类型，是“泛型进入标准库”的标志性事件，也说明官方认可了泛型在日常代码里的位置。
import (
"maps"
"slices"
)
nums := []int{5, 2, 8, 1, 9}
slices.Sort(nums) // [1 2 5 8 9]
fmt.Println(slices.Contains(nums, 5)) // true
fmt.Println(slices.Index(nums, 8)) // 3
uniq := slices.Compact(nums) // 相邻去重
fmt.Println(slices.Equal([]int{1, 2}, []int{1, 2})) // true
m := map[string]int{"a": 1, "b": 2}
keys := slices.Sorted(maps.Keys(m)) // ["a" "b"]，泛型遍历键并排序
注意 slices.Sort 要求元素满足 constraints.Ordered，而 maps.Keys/Values 要求键可比较（comparable）。这正是泛型约束在底层默默帮你把关：一旦传入不可排序的类型，编译期就会直接报错，而不是等到运行时 panic。把业务里的排序、去重逻辑迁移到这两个包，能少写大量样板代码。
但也要克制：如果只在一个小函数里排一次序，直接调用标准库即可，不必自己再包一层泛型；泛型的价值在于“多处复用、类型各异”的场景。判断标准很简单——同一段逻辑是否为三种以上类型各写了一遍？
八、常见坑与最佳实践
| 坑 | 现象 | 对策 |
|---|---|---|
约束漏写 ~ | 自定义类型（如 type ID int）不满足约束 | 约束里用 ~int 而非 int |
| 用 any 接收一切 | 失去类型安全，等于回到 interface{} | 只在“真的不关心类型”时用 any |
| 约束过宽 | 函数体内无法调用期望的方法 | 约束只声明真正用到的最小能力 |
| 过度泛型化 | 可读性下降，编译变慢 | 单类型就够时不要用泛型 |
8.1 与 CI / 容器 / 编辑器协作
泛型代码同样要走标准工程流程：用 GitHub Actions 跑 go test ./... 与 go vet，把编译期错误挡在合并前；用 Docker 多阶段构建生成精简镜像；在 VS Code 里装 Go 官方插件即可获得泛型重构、类型提示与内联报错。把缓存、工具函数沉淀为内部包，配合 PostgreSQL 等持久层使用，能让业务代码更薄、更稳。
九、结语
Go 泛型不是用来替代接口的银弹，而是补齐了“同构数据的类型安全复用”这一块短板。记住三个要点：用类型参数消除重复、用约束（尤其 ~T）精确表达需求、用 any 要克制。当你准备为第 N 种类型再写一遍一样的循环时，就是泛型登场的最佳时机。
落地清单：① 先确认是否有“多类型同构”的重复代码，没有就别上泛型；② 约束只声明真正用到的最小能力，能用 ~T 就别写死具体类型；③ 优先复用标准库 slices/maps 等泛型包，少造轮子；④ 写好单元测试覆盖边界类型，让编译期安全真正落地到仓库里。把这套习惯固化下来，泛型会从“语法糖”变成你日常提速的利器。
