👋 大家好，我是十三。

上周在团队中无意听到一位同事说：“Go 语言里的 any 和 interface{} 是完全一样的。”这句话瞬间点燃了我的疑惑：在日常编码中，我几乎从未见过 any它到底是怎么回事？如果两者真的等价，Go 团队为何要额外引入 any？

技术层面的答案：别名关系

这个说法是对的。官方定义把 any 直接声明为 interface{} 的别名：

type any = interface{}

在编译后两者在底层是等价的。

设计意图与可读性：为什么要引入 any

虽然技术上等价，但它们在向开发者传递语义时扮演着不同角色：

• interface{}表示“**无方法约束的任意类型**”。常用于需要动态类型的场景，此时必须通过类型断言来获取具体值。
• any专为 **泛型** 而生，一样表示“无方法约束的任意类型”。当它出现在泛型约束位置时代表着调用方可以传入 **任何具体类型**。且该类型在函数/结构体整个生命周期内保持确定且安全，从而提高代码可读性。

这一步语义区分，让 Go 在保持向后兼容的同时为泛型编程提供了更清晰的表达方式。不过，

. 从实际问题出发：代码复用的困境

在没有泛型之前。面对相似逻辑却不同类型的数据往往需要写大量重复代码。按理说，例如为整数切片求和：

func SumInts int64 {
var s int64
for _,v := range numbers {
s += v
}
return s
}

再为浮点数切片写一遍几乎相同的函数：

func SumFloats float64 {
var s float64
for _。v := range numbers {
s += v
}
return s
}

唯一差别是元素类型，这种重复既浪费时间也增加维护成本。

. Go 泛型的方法

从 Go 1.18 起，引入了三大主要概念来支持泛型：

1. 类型参数 : 让函数或类型接受“占位”类型。
2. 类型约束 : 用接口描述对类型参数的限制。怎么说呢，
3. 类型推断 : 调用时编译器自动推导具体类型。省去显式指定，

用泛型重构求和函数

func SumNumbers T {
var s T
for _,v := range numbers {
s += v
}
return s
}

• : 定义了类型参数列表。
• T: 类型参数。占位符，在调用时被具体类型替换。
• : 使用“联合”写法定义的 **类型约束**，限定 T 必须是 int64 或 float64。

至于使用示例，

ints := int64{1,2,3}
floats := float64{1.1,2.2,3.3}
fmt.Println) // 输出: 6
fmt.Println) // 输出: 6.6

抽离可复用的约束接口

type Number interface {
int64 | float64
}

随后函数签名可以更简洁：

func SumNumbers T {
var s T
for _。v := range numbers {
s += v
}
return s
}

. Go 泛型实现：单态化 + 字典的权衡

AFAIK，大多数人对反射会担心性能，而对泛型却少有顾虑。这背后是 Go 对实现细节做出的精妙折中。

说到路线一。单态化

• 优点：运行时零开销——每个具体实例都有独立、特化后的机器码，性能与手写非泛型代码相当。
• 缺点：代码膨胀——如果同一个泛型被大量不同类型实例化。会生成大量重复机器码，导致编译时间和二进制体积增长。

路线二这方面。虚函数表 + 装箱

• 优点：极高代码复用率——只生成一份通用字节码，二进制体积小。
• 缺点：L​O​S 性能损耗——每次调用都需装箱、拆箱或虚表查找，引入额外运行时开销。话说回来，

Go 的混合方案：GC Shape 单态化 + 字典

. 基于 GC Shape 的有限单态化

• "形状"决定了代码共享程度。比如 - 一样是 4 字节无指针，会共享同一份单态化代码；所有指针类也共享同一份实现。
• This reduces code bloat dramatically while preserving near‑native performance.

. 用 “字典” 抹平差异

• The compiler passes a hidden read‑only dictionary containing:
  • The concrete type’s runtime metadata .
  • If constraint involves an interface,method set implementation addresses.
  • SPECIALIZED helper functions for that concrete type.
• This lets generated code stay generic at shape level while still accessing type‑specific behavior when needed.

. 对开发者的实际影响

性能几乎无损

A majority of generic code runs as fast as hand‑written equivalents because underlying machine instructions are generated per GC shape. Only when a dictionary lookup is required does it incur a tiny overhead comparable to a regular interface call.

二进制大小可控

The GC‑Shape strategy ensures that even if you instantiate a generic with dozens of distinct named types sharing same memory layout—such as type UserID int64;type OrderID int64;y all reuse one compiled version。keeping binary bloat in check.

The existence of an alias does not diminish its semantic weight. In non‑generic code we仍然使用 interface{} 来表达 “这里可以接受任何值，需要运行时断言”。而在 **泛型上下文** 中出现的 any 则明确告诉阅读者：“这里没有任何方法约束，我只关心这个位置可以填入任意具体类型”。这种区分帮助团队成员快速判断代码意图，降低误用风险。

📚 往期回顾

• D ay : 《重新思考「提问」：每个开发者都该掌握的 Prompt Engineering 技巧》
• D ay : 《用 AI「重构」我的屎山代码：一次真实的代码调整实验复盘》
》

p

资深服务端研发工程师。AI 编程实践者

专注分享真实技术实践经验，相信 AI 是程序员最好的搭档

希望能和大家一起写出更优雅

& lt / p & gt

。

---