泛型方法

Go 1.18 引入泛型时，类型和函数都能声明类型参数，方法不能。

Go 1.27 补上了这半边，具体方法可以带类型参数了。

原文：Generic Methods

1.18 留下的空位

类型有泛型、函数有泛型，方法没有：

// 1.18 就有：类型参数化
type List[E any] struct {
    elem E
    next *List[E]
}

// 1.18 就有：函数参数化
func Sort[E cmp.Ordered](s []E) { /* ... */ }

// 1.27 之前写不出：方法参数化，编译器直接报错
func (List[E]) Map[R any](f func(E) R) List[R]

方法没有泛型的代价

List[E] 想把每个元素映射成别的类型，1.18 能写的方法只能把目标类型定死：

// 1.18：源类型 E 泛化了，目标类型 string 写死在签名里
func (List[E]) ToString(f func(E) string) List[string] { /* ... */ }

源类型随便，List[int] 配 strconv.Itoa、List[[]byte] 配 hex.EncodeToString，最后都得到 List[string]：

NewList(1, 2, 3).ToString(strconv.Itoa)                    // [1 2 3]
NewList([]byte("Hallo Welt")).ToString(hex.EncodeToString) // [48616c6c6f2057656c74]

目标类型只有 string 一种时这样够用；想要 List[bool]、List[float64]，方法就得每种重写一份。1.18 的变通是包级泛型函数，把目标类型也参数化：

// 1.18 变通：连目标类型一起参数化
func MapList[E, R any](l List[E], f func(E) R) List[R] { /* ... */ }

这样也能用，但代价有二：

// 代价一：挤占包作用域——每个支持映射的类型都带来一个 MapXxx
// 代价二：链式调用"由内而外"读，第一步反而嵌在最里面
MapList(MapList(NewList(0, 2, 4), add(2)), divideBy(2)) // [1 2 3]

1.27 方法补上类型参数

// 1.27：目标类型参数化，作用域收进类型本身
func (List[E]) Map[R any](f func(E) R) List[R] { /* ... */ }

新旧对比，同一个调用链：

// 旧（1.18 变通）：由内而外
MapList(MapList(NewList(0, 2, 4), add(2)), divideBy(2)) // [1 2 3]

// 新（1.27）：从左到右
NewList(0, 2, 4).Map(add(2)).Map(divideBy(2)) // [1 2 3]

函数变通的两个代价一起消掉了。Map 成为 List 的方法，不占包作用域；链式读法是自然的方向。这就是这项更新的核心：组织。方法表达式能把任何方法（包括泛型方法）转成等价函数，旧的调用结构随时找得回来：

f := List[int].Map[int]
f(f(NewList(0, 2, 4), add(2)), divideBy(2)) // [1 2 3]

解耦

组织 ≠ 接口实现

type I interface {
    M()
}
type T struct{}
func (T) M[P any]() { /* ... */ } // 具体泛型方法

T.M[int] 实例化后的签名和 I.M 一模一样（都是 func M()）。但 T 不实现 I。

接口实现是类型的属性，不是方法的属性。T 声明的是未实例化的 T.M，接口方法集要求的却是确切的 M()。

给具体方法加类型参数，不影响接口实现的任何规则，纯粹是让方法多承担一层「围绕类型组织代码」的职责。1.27 认为这值得，接口方法依然没有，那是真的难。

接口方法为什么难

分包编译

接口值是个盒子，装的值可以是任何实现该接口的类型。编译器必须保证 i.M() 可能路由到的每一个 M 都有代码存在。非泛型方法下没问题——编译器在类型声明处就把所有方法的代码生成好。

但两个包分开编译，main 包把 T{} 传给 p.F 时，不知道 p.F 内部会怎么用这个值：

// -- package main --
func main() {
    p.F(T{})
}

// -- package p --
type I interface {
    M[P any]() // 假设接口方法能带类型参数，编译不通过
}
func F(i I) {
    i.M[int]() // main 包看不到这一行
}

要覆盖 p.F 里所有可能的用法，编译器只能为每个可能的类型参数组合各生成一份实例化。类型参数是开放集合，实例化数量不可控，编译时间和产物体积都会爆炸。

替代方案是装箱。方法参数按约束接口的值传递、共享一份代码，代价是所有调用（包括直接调用）都背上间接开销。两个都不划算，接口方法维持不带类型参数。

上面是 GPT 分析的，部分具体内容详情我也不太明白，大概就是分包编译的时候接口方法接收值为泛型的时候认不出这个值的类型，导致编译的时候会出问题。

并且 Go 1.27 的编译器里面也明说了：

// D:\GoLand\SDK\go1.27.1\src\cmd\compile\internal\syntax\parser.go:1823
p.errorAt(pos, "interface method must have no type parameters")

在接口方法里面的函数如果不是固定签名，解析阶段会直接报错。泛型参数可以挂在类型上，但不能挂在方法上。

// 接口类型参数化：完全合法
type Repo[T any] interface {
    Find(id string) T   // 方法签名里用了 T，但没有自己的 [P any]
}

// 接口类型参数化，但是接口方法入参泛型化：不合法
type Repo[T any] interface {
    Find[P any](id P) T
}

边界

接口方法不能声明类型参数，type I interface { M[P any]() } 是语法错误。
泛型方法和其他泛型一样，必须先实例化才能调用——显式 T.M[int]() 或隐式推断。

[Golang] GO 1.27泛型方法更新