聊聊Go泛型在真实业务中的适用与滥用

Go 1.18 发布泛型已经过去好一阵子了，社区里从最初的“全民写泛型”到现在的“冷静期”，也算是走完了一个典型的技术炒作周期。作为一个整天跟真实业务死磕的开发者，我想聊聊我在实际项目中观察到的、以及自己踩过坑之后的一些思考。

什么时候泛型是真的“雪中送炭”

在真实业务里，泛型最值得用的地方不是那些花哨的抽象玩法，而是集中在“基础设施”类代码里。凡是涉及对多种类型做同样的机器性操作，泛型基本就是正解。

我自己感觉得最明显的是写缓存封装和工具库的时候。比如你有个方法要从 Redis 里取结构体列表，没泛型的时代要写 GetUsers、GetOrders、GetProducts 三套几乎一模一样的代码，改个序列化就要同步三个地方；有了泛型后只需要封装一个 GetList[T any](ctx context.Context, key string)，去那边一把梭，清爽得很。

再有就是类似 containers 里面那种数据类型结构（栈、队列、Set），这种纯粹在内存里存储、不需要关心具体业务含义的数据结构，恰好是泛型最完美的应用场景。它们是“形而上”的容器，天生就该泛型。

还见过一个挺漂亮的业务内应用：要做多来源数据统一适配，各来源的原始结构体是不同的，但进入统一处理管线后结构语义一致。如果不用泛型，就得写一堆类型断言的 “type switch” 大法。把“从 A 转换成 T”和“从 B 转换成 T”的映射逻辑分别封装成泛型方法，至少代码的可读性提升了一半。

滥用是怎么开始的：无脑抽象

然而泛型也有它迷人的陷阱，最大的一个就是——让开发者在不该抽象的地方过度抽象。

最阴间的写法，是用泛型模拟面向对象的继承体系。比如你有一个 Animal 接口，下面有 Dog、Cat，有人非要写 type Cage[T Animal] 然后搞什么“泛型实现多态”，结果业务一加需求就发现 Cage[Dog] 和 Cage[Animal] 之间的类型互转处处不顺。泛型不是用来替代接口的，二者解决的问题维度完全不同。

还有一类特别典型的滥用表现在函数定义成“为了泛型而泛型”。我接触过一个代码库，一个简单的 FilterByStatus 方法硬是写成 Filter[T any, K comparable](items []T, keyFunc func(T) K, target K) []T，调用的时候客户还得读一遍他的 keyFunc 才知道是在做什么。好吧，如果你的所有业务对象都有 Status 字段，你直接定义接口约束比这个好读一百倍。

更常见的组合拳是一层套一层的泛型和闭包。业务上明明一个 for 循环加 append 就能解决的问题，非要用 genericReducer 加 genericTransformer 组合出函数式风格。结果代码量从 3 行变成 20 行，还额外引入了调试堆栈的复杂度。这类代码的性能倒未必差多少，但团队里的人看一次骂一次，真的维护不动。

业务代码中“克制”比“炫技”更重要

我之前看到某种论调说“泛型让 Go 变得跟 Java 一样了，大家应放开胆子使用”。这话有它的合理性，但如果展开到“所有写业务逻辑的地方都要上泛型思路”，那就走向了另一个极端。

一个很核心的判断标准是：你的代码是否同时被多个业务方复用？ 如果你的这个组件/方法只需要服务一个明确的业务需求，调用方就两处，写出来的数据形态是确定的——那直接写具体类型就好。为两三个调用点引入泛型，除了增加阅读门槛，收益实在微乎其微。

实际业务里，维护“复杂度”的成本是远比写的时候要高的。你要是把一个方法写成泛型的，未来换人接手后就很难拍板改结构了——因为泛型给了它“通用能力”的滤镜，新人还以为这个接口是他不能动的领域模型。真实业务中坑就是这么埋下的：写的时候多费了点脑筋，读的人却要费十倍的脑筋去复原你的脑回路。

怎么拿捏边界

我的经验很简单：

**底层的基础工具库（没有业务语义、纯粹的数据加工逻辑）——放心写泛型；中层的领域服务、业务编排——写得越具体越尽量别碰泛型。** 即便真要抽象共同逻辑，优先想想是不是一个明确的 interface 就够了。

具体判断时，多问自己：“如果我这里用一个具体类型，代码会变得更难维护吗？”，而不是问“我能不能用泛型扩展无限可能的未来场景”。那种为了未来可能多出的类型提前铺好泛型的，绝大多数都是过度设计。真实世界的未来展望往往是：需求没来，代码倒是先烂了。

泛型是 Go 语言补上的一块漂亮拼图，它确实解决了很多痛点，但它也只是工具箱里的一把扳手。没必要因为它是新的，就拼命在账本的每一页上都用一次。谨记让代码的复杂度和业务真正需要的抽象程度成正比，这大概才是社区里最应该达成共识的事。