Go的编译器在编译1.18版本引入的泛型时采用了一种被称为GCshape模板化的技术。从历史上看，语言通过完全的单态化（为每种类型实例生成单独的机器码，导致二进制膨胀）或通过装箱（以运行时开销和分配为代价消除类型）来实现泛型。Go面临的问题是如何支持高性能的系统编程，二进制大小很重要，但又不完全牺牲执行速度。
解决方案涉及根据它们的GC形状分组具体类型，GC形状由类型的大小和指针位图（类型内指针的模式）定义。编译器为所有共享相同GC形状的类型生成单个函数实例，传递包含类型元数据的运行时字典作为隐式参数。
// *int和*string共享相同的实例化 // 因为它们具有相同的GC形状（单个指针）。 func Identity[T any](x T) T { return x } func main() { Identity((*int)(nil)) // 使用实例化#1 Identity((*string)(nil)) // 使用实例化#1（相同形状） Identity(42) // 使用实例化#2（标量，没有指针） }
我们的团队正在构建一个高吞吐量的事件处理管道，使用泛型中间件处理程序Handler[T Event]。我们需要处理五十种不同的事件类型，同时保持低延迟和合理的二进制大小以便容器化部署。
第一个方法使用interface{}和类型断言，依赖于运行时类型切换。这提供了灵活性，并在较旧的Go版本中有效，但引入了显著的分配开销——每个用接口包裹的事件都需要堆分配——并消除了编译时类型安全，当类型不匹配时在生产中导致恐慌。
第二种方法涉及使用go generate和第三方工具进行编译时代码生成，以创建HandlerClickEvent、HandlerPurchaseEvent等。这提供了最佳性能而没有运行时开销，但支持五十种事件类型时使我们的二进制大小膨胀了40MB，并在更新生成器模板时造成维护噩梦。
我们选择了第三种方法：使用Go的原生泛型，仔细关注GC形状。我们确保事件类型是指向结构体的指针（统一GC形状），允许编译器重用实例化。我们接受了字典查找带来的轻微开销以交换仅增加2MB的二进制大小。结果是与interface{}相比，延迟降低了15%，二进制体积也在与全代码生成相比时可控。
运行时字典如何为共享泛型实例提供特定类型的信息？
字典是一个包含指向类型描述符（_type）、方法表（itab）和GC元数据的指针的结构。当编译器为像func Print[T any](x T)这样的泛型函数生成代码时，它将字典作为隐式首个参数传递。为了调用方法x.String()，生成的代码在字典中查找方法指针，而不是编译直接调用，使得同一机器码能够处理T=bytes.Buffer和T=strings.Builder，尽管它们具有不同的方法实现。
为什么两个不同的指针类型可能共享一个泛型实例，而它们的元素类型需要单独的实例？
Go通过GCshape分类类型，关心的仅是与垃圾收集器和分配器相关的内存布局。*int和*string都是由一个包含指针的单个机器字组成，将它们放入相同的形状类。相反，int没有指针，并且按照特定大小对齐，而string是一个包含指针和长度的双字结构。由于它们的内存布局不同，因此需要单独生成代码路径以处理正确的垃圾收集和内存寻址。
在泛型约束中使用值接收器与指针接收器的性能影响是什么？
当泛型函数在类型参数T上调用方法时，编译器必须生成适用于任何可能的T的代码。如果约束需要值接收器func (T) Method()，但具体类型很大，编译器可能被迫传递字典并执行间接调用，防止内联。使用指针接收器func (*T) Method()通常可以实现更好的优化，因为指针类型更频繁地共享GC形状，并且在特定实例上下文中编译器可以更容易地去虚拟化调用。