Go 1.27 泛型方法：方法能自带类型参数，接口方法仍然不行
参考：Go 1.27 Release Notes、Generic Methods（官方博客）、Go 语言规范、提案 golang/go#77273（2026-02-25 accepted）。
最小对比
Go 1.18 起，泛型只能是包级函数或类型：
// after Go 1.18
func MapList[E, R any](l List[E], f func(E) R) List[R]
代价是 MapList 落进包作用域。支持 map 操作的数据类型一多，包级名字就开始拥挤；链式调用还得由内向外反着写：
fmt.Println(MapList(MapList(NewList(0, 2, 4), add(2)), divideBy(2)))
Go 1.27 允许方法声明自己的类型参数：
// after Go 1.27
func (List[E]) Map[R any](f func(E) R) List[R]
fmt.Println(NewList(0, 2, 4).Map(add(2)).Map(divideBy(2))) // [1 2 3]
规范里的产生式：
MethodDecl = "func" Receiver MethodName [ TypeParameters ] Signature [ FunctionBody ] .
和泛型函数一样，泛型方法必须先实例化（显式或隐式）才能调用、才能当值用。想保留由内向外写法，用 method expression，且要写全实例化：
f := List[int].Map[int]
fmt.Println(f(f(NewList(0, 2, 4), add(2)), divideBy(2)))
标准库对应改动是 math/rand/v2：原先只有 Int32N、Int64N、IntN 三个方法和包级泛型函数 N[Int intType](Int) Int，1.27 新增方法 (*Rand) N[Int intType](n Int) Int。
函数类型推断也推广到所有把泛型函数赋给、或转换成匹配函数类型的上下文，包括复合字面量、类型转换、通道发送：
func GenericFormatter[T any](v T) string { return fmt.Sprintf("value: %v", v) }
type IntFormatter func(int) string
formatters := []IntFormatter{GenericFormatter}
fn := IntFormatter(GenericFormatter)
ch := make(chan IntFormatter, 1); ch <- GenericFormatter
限制
接口方法不能声明类型参数，泛型方法也不能实现接口方法。接口实现是（可能已实例化的）类型的属性，不是某个方法的属性：
type I interface{ M() }
type T struct{}
func (T) M[P any]() {}
var _ I = T{} // error: T does not implement I (wrong type for method M); have M[P any](); want M()
type Stringer interface{ String() string }
type H struct{}
func (H) String[P any]() string { return "" }
var _ Stringer = H{} // error: cannot use H{} ... (wrong type for method String); have String[P any]() string; want String() string
语法层面也不允许接口方法带类型参数（接口方法可以用接口声明本身的类型参数）。原因是：若接口里有 M[P any]()，别的包对 T{} 做任意实例化时，编译器就得为所有可能的类型实参生成 T.M 的代码；把方法实参 boxed 成约束接口值能共享代码，但直接调用已实例化方法也要付间接调用开销。
reflect 拿不到：反射没有实例化泛型的机制，泛型方法无法按名字或索引访问。1.27 标准库唯一的泛型方法就是 (*Rand).N。
go.mod 版本门槛，go 1.26 直接编译失败：
generic method requires go1.27 or later
实例化递归被拒。实现仍受 shape stenciling 限制：泛型类型实例化时必须生成它的所有方法，因为该类型可能在别的包里用于满足接口。
type T[P any] struct{}
func (T[P]) m() T[T[P]] { panic("unimplemented") }
报 instantiation cycle: P instantiated as T[P]；换成顶层泛型函数 func m[P any](T[P]) T[T[P]] 却能编译，因为函数只在被调用时才实例化。
工具影响：go/types.Signature 的 TypeParams() 现在对方法也可能非 nil，RecvTypeParams() 才是接收者来源的参数。处理 go/types 的工具若假设“方法只有接收者的类型参数”，需要改。
接收者一侧还有一条：别名不能是泛型的，也不能表示已实例化的泛型类型。
什么时候仍写顶层函数
操作跨多个类型、不必挂在某个接收者上时，顶层泛型函数仍然是自然选择——它不绑定接收者，也不需要 List[int].Map[int] 这种实例化写法。需要被接口方法实现、需要通过反射访问的，只能走接口方法或顶层函数。类型参数上出现递归定义（上面 m 的例子），顶层函数能编译而方法不行。库要兼容 go 1.26 及更早版本时，go.mod 里那句门槛会直接把泛型方法挡在外面。