历史： 在 Go 1.18 之前，语言缺乏参数多态性，迫使开发者在 interface{}（导致堆分配和装箱开销）或代码生成（导致二进制膨胀）之间进行选择。在设计泛型时，Go 团队明确拒绝了 C++ 模板模型的完整单态化——每个不同类型的实例化都会产生重复的机器代码——这是因为担心大型云原生应用程序在链接成千上万个包时会导致二进制大小爆炸。
问题： 纯单态化会为 Process[int] 和 Process[uint] 生成单独的汇编块，尽管它们都是 64 位整数，这会浪费指令缓存和磁盘空间。相反，通过装箱实现泛型（如 Java）会强迫值类型落在堆上，破坏 Go 在系统编程领域的重要零分配性能特征。挑战在于保护编译时类型安全和零成本值语义，同时避免 N 次代码重复的问题。
解决方案： Go 采用 GC 形状模板 结合 运行时字典。编译器按 GC 形状 将类型分组——根据大小、对齐和指针位图定义，而不是根据确切的类型标识。具有相同内存布局的类型（例如 []int 和 []string，都是带有指针、长度和容量的头结构）共享相同的实例化机器代码模板。对于类型特定的操作，如方法分派或类型断言，编译器传递一个隐藏的 运行时字典，其中包含元数据偏移量。这确保了 Point{X:1, Y:2} 和 Vector{X:1, Y:2} 共享代码，同时保持值类型在栈上不被装箱。
我们正在开发一种高性能的列存储引擎，需要一个通用的 SkipList 实现来索引 int64 时间戳和自定义 Decimal128 结构体（16 字节，两个 uint64 字段）。使用 interface{} 的初步基准测试显示 35% 的 CPU 时间用于运行时堆分配和接口间接调用，这对于我们的亚微秒延迟要求来说是不可接受的。
我们考虑了三种架构方法。首先，通过 go generate 和 text/template 进行完全单态化，生成专用的 SkipListInt64 和 SkipListDecimal 实现。这消除了分配，但在支持十二种不同数值类型时，导致我们的二进制大小增加了 22MB，违反了我们的无服务器部署限制。其次，使用 unsafe.Pointer 和反射的统一实现手动管理内存。这保持了二进制大小的最小化，但引入了灾难性的复杂性，要求手动指针算术，在测试期间打破了 Go 的垃圾收集器不变性。
我们选择了第三种方法：原生 Go 泛型，仔细关注 GC 形状分组。我们将 Decimal128 结构体对齐，以匹配 [2]uint64 的内存布局，确保它与其他 16 字节值类型共享模板代码。通过分析 go tool objdump 的编译器输出，我们确认 SkipList[int64] 和 SkipList[uint64] 共享相同的汇编块，而 SkipList[string] 由于其包含指针的位图而正确使用了单独的模板。这种混合方法将二进制大小减少了 58%，与代码生成相比，同时保持了零分配吞吐量。最终效果是 interface{} 版本的延迟提高了 4 倍，二进制大小低于 30MB。
为什么两个具有相同字段类型的不同结构体类型有时会生成单独的泛型实例，而结构体和基本类型的类型别名可能会共享代码？
这是因为 GC 形状分组依赖于完整的运行时类型描述符，包括指针位图和填充，而不仅仅是表面的字段类型。如果 type A struct { x, y int } 和 type B struct { x, y int } 在不同的包中定义，它们共享相同的 GC 形状和模板。然而，*type C struct { x int; y int } 具有与 type D struct { x, y int } 不同的指针位图，迫使生成单独的机器代码。相反，type MyInt int 和 int 共享形状，但 struct { _ int; x int } 和 struct { x int } 由于对齐填充可能会有所不同。理解垃圾收集器需要每个活动变量的准确堆栈图，解释了为什么布局身份优于名义类型身份。
在泛型类型参数上的方法调度与直接具体调用有何不同，这种开销为何在没有完全单态化的情况下是不可避免的？
在调用泛型类型参数 T 的方法时，编译器通过 运行时字典 发出间接调用，而不是直接的函数地址。与接口调用（通过 itab 在运行时解析方法）不同，泛型字典条目在编译时解析，但作为隐藏参数传递。这引入了一层间接性（通常为 2-5 纳秒），与零成本单态化代码相比。候选人常常假设泛型相对于手动专门化代码完全没有开销；实际上，字典查找妨碍了单态化所允许的某些内联优化，尽管这仍然比 reflect.Value.Call 快几个数量级。
为什么使用空标识符字段（例如，struct { _ int64; x int64 }）实例化泛型类型可能迫使编译器生成唯一模板，从而增加二进制大小？
空字段占用空间，并且即使没有命名也会影响结构体的指针位图，可能会改变 GC 形状。struct { _ int64; x int64 } 的大小和对齐在某些体系结构下与 struct { x int64 } 不同，导致编译器将其分配到不同的模板组中。此外，如果空字段是指针类型（**_ int*），它会改变垃圾收集器对该类型的跟踪要求，强制进行单独的堆栈图。开发人员在优化二进制大小时必须认识到，GC 形状是由完整的内存布局决定的——包括填充和空字段，而不仅仅是语义相关的数据成员。