这篇文章讨论 Go 新增 generic methods（泛型方法）的提案，它补上了 Go 1.18 之后泛型只覆盖函数和类型、却不能把类型参数放到方法上的缺口。争论点不只在语法本身，还在 Go 的 interface 是按方法集做结构匹配，且经常依赖动态类型断言，所以编译器很难像普通泛型那样提前决定要生成哪些特化版本。评论里有人拿 Rust 的 dyn-compatible traits、Java 的 type erasure、.NET 的 monomorphization 来类比不同语言如何处理类似问题。也有人把它放进 Go 的长期演进史里看：从 GOPATH（Go 早期工作区模式）、modules（Go 模块系统）到 errors、min/max 等功能，Go 一直在补最初刻意不加的东西。
不少评论把 generic methods 看成实打实的 API 改善。以前为了保持接口整洁，很多人只能写奇怪的 package-level generic func、手工重复代码，或者退回到 reflection。现在把类型参数挂到 method 上，被认为更适合 data access 这类场景，也更容易把已有库重构得顺眼一些。支持者的核心感受是：这不是炫技，而是把原本很别扭的写法变成可读、可维护的表达。
反对或保留意见主要集中在实现语义和性能上。有人指出如果靠 runtime reflection 绕过去，会带来看似无关改动导致的性能断崖，而且等于要维护一套 runtime 和一套 compile-time 的 generics 实现。另一些评论拿 .NET 的 monomorphization、Java 的 type erasure 来说明：是否按类型实例化会影响 stack layout、参数传递和 primitive 支持，绝不是简单的语法糖。更关键的是，Go 的 interface type assertions 和动态派发使编译器无法提前知道该为哪些 interface/implementation 生成代码，所以 generic methods 仍然不能顺手满足 interface，高阶抽象如 `Monad[T]` 之类也还是卡住。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11] [来源12] [来源13]
这条线的争论不在语法，而在 Go 团队到底是不是一直都这么打算。有人强调 FAQ 里的措辞只是“we do not anticipate”，不是绝对的“never”，而且最初的 generics proposal 里本来就承认需要再想办法。另一派则觉得 Go 社区长期把明显缺陷说成“哲学选择”，等功能 finally 被补上后又改口说只是时机未到，这种来回 retcon 让人很难信任。讨论里还顺带扯到 modules、GOPATH、errors、min/max、iterators，作为“先否认、后补票”的一串例子。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11] [来源12] [来源13] [来源14]
也有人坚持 Go 的价值就在于克制和慢慢长成。对这部分人来说，Go 保持小而统一、编译快、读写都容易上手，比一开始就把语言做成大而全更重要。评论里拿 ANSI CL、Objective-C、Scheme、Elixir、Clojure 之类作对比，赞赏它们在有限目标下的清晰度和完成度。这个立场的共同点是：不是所有流行语言都需要把每个现代特性都塞进去，慢一点反而更稳。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11] [来源12] [来源13]
批评者则认为 Go 的问题不是“少加了一个功能”，而是早期基础设计就有不少坑。最常被点名的是 lack of generics、nil、iota/enum、GOPATH、error handling 以及 uint128 之类一直拖着不补的东西。有人说 Go 的成功更多是靠 Google 背书和清晰的 use case，而不是因为语言本身在关键设计上无可挑剔；也有人直接说现有 generics 设计在主流语言里都算很笨重。另一类评论把它和 Java、Rust、Zig、TypeScript 对照，认为别的语言至少会承认缺点并持续修正，Go 却常被批评为“先说不需要，再慢慢补”。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11] [来源12] [来源13] [来源14] [来源15] [来源16] [来源17]
泛型方法: 带类型参数的方法，可在调用时针对不同类型复用同一实现。
单态化（monomorphization）: 为每个具体类型生成专门代码的做法，通常用于保留性能。
类型擦除（type erasure）: 把泛型在运行时抹平的方案，Java 常见，通常会带来 boxing 或额外转换。
运行时反射（runtime reflection）: 在运行时检查和操作类型信息，用来绕过静态泛型限制，但通常更慢。
dyn-compatible: Rust 中能通过 trait object 做动态派发的 trait 约束；一旦有 generic method 往往就不再 compatible。
结构化类型（structural typing）: 按方法集是否匹配来判断接口实现的类型系统，类似 static duck typing。
interface type assertion: Go 里把 `any` 之类的接口值动态断言成另一种接口或具体类型的机制。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。