Go 1.27 泛型方法：能链式调用，但反射扫不到它

来源：Go 官方博客《Generic Methods》，Mark Freeman，2026-08-26，go.dev/blog/generic-methods

Go 1.18 引入了泛型，但只给了类型和函数，方法没有。当时泛型提案的理由是：泛型接口方法难以高效实现，所以连具体（非接口）方法也一并排除，背后的观点是“方法主要是实现接口的手段”。Go 1.27 换了看法，给具体方法加上了类型参数。

从组织代码的角度看：方法需要自己的类型参数

List[E] 参数化了源类型，但转换之后的目标类型取决于传入的函数，这一点在 Go 1.18 里表达不出来：

type List[E any] struct {
	elem E
	next *List[E]
}

func NewList[E any](elems ...E) List[E]
func (List[E]) String() string

想要的 API 是：

func (List[E]) ToString(f func(E) string) List[string]

调用侧应该长这样：

NewList(1, 2, 3).ToString(strconv.Itoa)

List[[]byte].ToString(hex.EncodeToString)
List[[]byte].ToString(base64.StdEncoding.EncodeToString)

Go 1.18 的绕法是把 R 提到函数级：

func MapList[E, R any](l List[E], f func(E) R) List[R]

代价有两个。一是占用了包级命名空间，MapList 这类名字会越积越多；二是链式调用得里朝外写：

MapList(MapList(NewList(0, 2, 4), add(2)), divideBy(2))

Go 1.27 的方法是：

func (List[E]) Map[R any](f func(E) R) List[R]

NewList(0, 2, 4).Map(add(2)).Map(divideBy(2))

（add、divideBy 为示意函数。）

内聚和可读性的差别在这两行里就很清楚了：类型自己带转换方法，调用顺序和阅读顺序一致。

方法表达式仍能把方法还原成函数

泛型方法没有破坏方法表达式。List[int].Map[int] 得到的就是普通函数形式：

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

和所有泛型一样，泛型方法在使用前必须实例化，显式写类型参数或者由编译器隐式推断都行。

边界一：接口方法不能声明类型参数，泛型方法也不能实现接口方法

这条最容易踩。看下面这段：

type I interface {
	M()
}

type T struct{}

func (T) M[P any]() {}

T{}.M[int]() // 合法

T{}.M[int]() 和 I.M 的签名都是 func M()，但 T 并不实现 I。

接口实现是（可能已实例化的）类型的属性，不是某个具体方法的属性。T 声明的是未实例化的 T.M，而不是 T.M[int]。T.M 没法参与接口实现。

要让 T.M 参与接口实现，接口里也得有泛型方法：

type I interface {
	M[P any]()
}

Go 1.27 的语法不允许接口方法声明类型参数，所以这段代码写不出来。

为什么不能有泛型接口方法

接口值是个盒子，装进去的类型必须实现接口，因此类型声明的方法集必须是接口方法集的超集。这个约束在跨包时会变得具体。

main 里调用 p.F(T{})，p 包里的 F 调用 i.M()。两个包分开编译，main 不知道 p.F 会怎么用 T{}。为了保证 p.F 可能调到的任何方法都存在，编译器在类型声明（或实例化）时就为所有非泛型方法生成代码。

如果 I.M 是泛型的，main 同样不知道 p.F 会用哪个类型参数去实例化 T.M。要覆盖任何用法，编译器就得用“每一个可能的类型参数”去实例化 T.M——在 Go 现有的实例化方式下不可行，因为每个类型参数都要生成专用代码。

另一条路是把方法参数装箱，按约束接口的值传递，各实例共享一份代码。但那样即使直接调用一个已实例化的方法，也要付间接调用开销。

结论就是 Go 1.27 的两句话：具体方法可以有类型参数；接口方法仍然不能有，泛型方法也不能用来实现接口方法。

边界二：泛型方法不在类型的方法集里

这是上面那条规则落到实际框架上的后果。类型的反射方法集里看不到泛型方法：

type Counter struct{}

func (Counter) Plain()        {}
func (Counter) Convert[U any]() {}

reflect.TypeOf(Counter{}).NumMethod() // 1

NumMethod() 返回 1，Convert 不在里面。依赖 reflect 扫描方法来做序列化、ORM 映射、RPC 注册、插件发现的框架，会直接漏掉这类 API。这不是框架的 bug，也不是编译器漏生成，是语言模型的一部分：T 声明的是未实例化的 T.M，反射拿不到一个确定的 M。

这类“方法消失了”的现象，在 Go 1.27 升级的实测笔记里也有记录（wujiachen.com.cn 的 Go 1.27 升级笔记，Counter 只有 Plain 和 Convert[U any] 时 NumMethod() 为 1）。

使用建议

泛型方法先别放进公共 API 边界。凡是会被反射扫描、被接口集合约束、被第三方框架按方法集发现的类型，加泛型方法前先想清楚：这些方法对框架是不可见的。

内部集合、管道、转换类的工具优先用。List[E].Map[R] 这种场景是它最舒服的位置：类型自己携带转换逻辑，调用链顺序即阅读顺序，也不需要往包级命名空间塞 MapList、FilterList 这类函数。