Go语言热点路径优化难题：泛型等抽象阻碍性能，复制代码或成无奈之选！

优化CPU密集型Go热点路径的笔记

2026年5月3日，在为[go-brrr](https://github.com/molecule-man/go-brrr)将Brotli移植到纯Go语言时，遇到惯用抽象使热点路径变慢，最快版本常需手动复制和专门定制的问题。

缺乏零成本抽象

在优化的热点循环中，泛型、多态调度（通过接口）和闭包常阻碍编译器生成与具体版本相同的代码。Go不会按使用方式内联这些调用，虽编译器有时能内联直接闭包调用或对接口调用去虚拟化，但实际遇到的模式中未这么做，只能承担调用开销。接口调用不被内联是因其允许运行时交换实现，而泛型虽允许编译时交换实现，但Go使用GC Shape Stenciling方法，类型参数上的方法调用最终仍通过接口风格调度。提案中提到方法调用在编译时无法完全解析时不会内联。

解决办法是不使用泛型等抽象，复制具体函数，但这会导致大量代码重复。如Brotli移植中有16个几乎相同的函数，仅调用的`hash`函数版本不同，无法通过抽象合并。复制代码解决了性能问题，却带来潜在重大维护问题，虽可通过代码生成缓解，但大量只有2 - 3个重复变体的情况引入代码生成不划算。

深入探究

通过实际代码库中的函数说明问题，给出具体函数`StoreConcrete`，并介绍了使用泛型、多态调度和闭包传递函数的参数化方法，分别给出`StoreGeneric`、`StoreInterface`和`StoreClosure`函数。

对其进行基准测试，环境为“go version go1.26.2 - X:nodwarf5 linux/amd64，goos: linux，goarch: amd64，pkg: hashdemo，cpu: 12th Gen Intel(R) Core(TM) i5 - 12500”，使用“go test -bench=. -benchmem -count 6 -cpu 1 | tee bench.txt；benchstat -filter '.unit:B/s' -col .name bench.txt”命令运行。基准测试代码展示了不同变体的测试函数。

测试结果显示，具体版本吞吐量为378.0 MiB/s，泛型版本为320.6 MiB/s，闭包版本为322.0 MiB/s，接口版本为274.3 MiB/s，与具体版本相比，泛型版本变化 - 15.18%，闭包版本变化 - 14.82%，接口版本变化 - 27.44%。

还给出了与具体版本、泛型版本、闭包版本和接口版本函数相关的汇编代码。所有变体的指令数量几乎是原始具体版本函数的两倍，额外的调用、参数重新加载、空指针检查和边界检查使吞吐量受影响。对比热点循环内部情况，具体版本和泛型版本在循环条件、哈希函数调用、边界检查等方面存在差异。