大家好，我是煎鱼。
自 Go 1.18 泛型正式落地以来，虽然解决了大家多年的 “心病”，但总感觉只有一半的爽快。为什么呢？
因为只能对 “函数” 和 “类型” 使用泛型，大家日常写的最多的“方法（Method）”被排除在外了。
这几年社区里关于 “泛型方法” 的呼声就没断过，但都被严辞拒绝了。（大雾
最近 Go 核心团队的大佬 Robert Griesemer 终于开悟了！！！不知道他经历了什么。
提交了一份新的提案：Proposal: Generic Methods for Go。
今天我们就来聊聊这个提案。（可惜是个阉割版泛型方法...）
背景：为什么之前没有？
我们先回顾一下，为什么 Go 1.18 的时候把 “泛型方法” 给砍掉了？
当时官方的理由主要卡在接口（Interface）上。
在 Go 的设计哲学里，方法的主要作用之一就是用来实现接口。如果允许具体类型的方法带泛型，那么逻辑上，接口的方法定义也应该支持泛型。
很无奈的是，实现 “泛型接口方法” 在技术上非常困难，或者说代价极大。
因为 Go 的接口实现是隐式的（Implicit），编译器在编译时无法知道哪个具体的泛型方法会被调用，这会导致运行时需要动态处理无限可能的实例化情况。
在最初的 Type Parameters 提案中，为了不把事情搞复杂，官方直接一刀切：方法不许带泛型。
社区的期望
社区对这个痛点反馈非常强烈。在 GitHub 上，相关 Issue（如 #49085）集齐将近 900 个 star。
大家非常期望有这个功能：
观念的转变
这次的新提案，核心在于 Go 团队观念的一个“大转弯”。
Robert Griesemer 在提案中表示，也许我们应该换个角度看问题：
具体方法（Concrete Method）不仅仅是为了实现接口。
方法本质上就是 “带接收者（Receiver）的函数”。既然泛型函数是允许的，那泛型具体方法也应该是允许的。
至于接口怎么办？提案给出的答案是：“分而治之”。
简单来说就是：允许具体类型的方法带泛型，但是接口里的方法依然不支持泛型。
如果你的泛型方法和接口方法签名对不上，那就对不上吧，不实现这个接口就是了。
这种 “虽不完美但有用” 的思路，正是这次提案的基础。
新提案介绍
语法变化
这个提案的内容其实非常直观。现在的 Go 方法声明长这样：
// 旧写法 func (r Receiver) MethodName(args...) { ... }提案建议改成这样，允许在方法名后面加类型参数：
// 新写法 func (r Receiver) MethodName[P any](args...) { ... }本质上，就是把方法看作是 “函数 + 接收者”，两者的语法规则统一了。
简单的例子
我们来看几个具体的代码示例，感受一下新写法。
假设我们要给一个结构体S定义一个泛型方法m：
type S struct { … } // 定义一个泛型方法 m，接收类型参数 P func (*S) m[P any](x P) { … }调用的时候，和泛型函数一样，可以显式传入类型，也可以让编译器自动推导：
var s S s.m[int](42) // 显式传入类型参数 int s.m(x) // 自动推导类型参数 P如果接收者本身也是泛型类型，也是完全没问题的：
type G[P any] struct{ … } // 接收者是 G[P]，方法本身又有新的类型参数 Q func (*G[P]) m[Q any](x Q) { … }这一套下来，写链式调用或者工具方法时，会舒服非常多。
这里的 “坑”：接口实现
重点来了，这里有一个必须要明确的限制。
虽然你可以写泛型方法，但它不能用来实现非泛型的接口方法。因为签名对不上。
举个官方给的例子。
假设有一个接口I：
type I interface { m(string) }在现在的 Go 里（包括这个提案落地后），你可以用一个实例化后的泛型类型来实现它：
type G[P any] struct{ … } func (G[P]) m(P) { … } var g G[string] var _ I = g // 合法：因为 G[string].m 的签名是 m(string)，匹配接口 I但是，如果你有一个带泛型方法的类型H：
type H struct{ … } func (H) m[P any](P) { … } var h H var _ I = h // 非法！这里报错会发现报错。那为什么报错？
是因为H.m的签名是m[P any](P)，这是一个泛型方法。而接口I要求的是m(string)。这两者是不匹配的。
泛型方法 m 永远无法匹配接口方法 m，因为接口语法目前不支持声明泛型方法。
另一个经典例子：Reader
再看个更实际的例子。比如我们想搞一个泛型的Reader：
type Reader struct{ … } func (*Reader) Read[E any]([]E) (int, error) { … }你可能会想，如果我实例化成Read[byte]，是不是就能实现io.Reader接口了？
答案是：不能。
即使你在脑海里把E替换成了byte，在 Go 的类型系统中，(*Reader).Read依然是一个泛型方法，而io.Reader里的Read是一个普通方法。它俩 “谁也不认识谁”。
这就很尴尬了，对吧？但这正是为了引入泛型方法所做的妥协。
实现细节
大家可能会关心：这玩意好实现吗？
会不会让编译速度变慢很多？
编译器层面
提案提到，其实改动不算大。
具体如下：
前端（解析器）：现在的解析器其实为了容错，已经能识别这种语法了（只是会报错）。改一下让它通过很简单。
后端（代码生成）：由于我们限制了只有具体类型（非接口）才能有泛型方法，这意味着在编译时，接收者的类型是确定的。 编译器可以把
g.m(s)这样的方法调用，悄悄重写成普通函数的调用。
举个例子：
type G[P any] struct{ … } func (G[P]) m[Q any](x Q) { … } var g G[string] g.m("hello")编译器本质上会把它翻译成类似这样的东西：
// 生成一个泛型函数 func f[Q any](g G[string], x Q) { // 调用方法表达式 G[string].m[Q](g, x) } // 然后调用它 f("hello")既然能转成泛型函数，那现有的泛型实现机制就可以复用了。
反射（Reflection）
这里有个点需要注意：泛型方法不支持反射。
这和目前的泛型函数一样。
reflect包目前没有机制去表示或实例化一个 “未实例化的泛型函数”。
想通过反射动态调用泛型方法，是行不通的。
总结
我们来梳理一下这个提案的核心观点。
具体如下：
允许给具体类型（struct 等）定义带类型参数的方法。
语法和泛型函数高度一致。
不支持在接口（interface）中定义泛型方法。
不匹配：泛型方法无法用来实现非泛型的接口方法。
这个新提案，虽然不能用来做接口多态，但在很多库的设计中（比如 ORM、工具类、集合库），我们并不总是需要接口，而是需要方法的链式调用和类型安全。
在这些场景下，这个提案简直是雪中送炭。
这算是一种 “实用主义” 的胜利吧。既然完美的（支持接口的）泛型方法太难做，那就先搞一个不完美但能用的。
这是一个阉割版的泛型方法。总好过没有？
关注和加煎鱼微信，
一手消息和知识，拉你进技术交流群👇
你好，我是煎鱼，出版过 Go 畅销书《Go 语言编程之旅》，再到获得 GOP（Go 领域最有观点专家）荣誉，点击蓝字查看我的出书之路。
日常分享高质量文章，输出 Go 面试、工作经验、架构设计，加微信拉读者交流群，和大家交流！
原创不易 点赞支持
