为何将interface{}转换回切片会产生额外堆分配？

在Go 1.19.5环境下，我们通过两个sync.Pool的基准测试，发现了明显的性能差异：

测试一：存储切片值到sync.Pool #

func BenchmarkPool(b *testing.B) {
    b.ReportAllocs()
    p := sync.Pool{New: func() interface{} {
        return make([]byte, 1024)
    }}
    for i := 0; i < b.N; i++ {
        bts := p.Get().([]byte)
        p.Put(bts)
    }
}

基准测试输出：

BenchmarkPool
BenchmarkPool-10        47578498            24.47 ns/op       24 B/op          1 allocs/op

测试二：存储切片指针到sync.Pool #

func BenchmarkPool(b *testing.B) {
    b.ReportAllocs()
    p := sync.Pool{New: func() interface{} {
        bts := make([]byte, 1024)
        return &bts
    }}
    for i := 0; i < b.N; i++ {
        bts := p.Get().(*[]byte)
        p.Put(bts)
    }
}

基准测试输出：

BenchmarkPool
BenchmarkPool-10        142008002            8.581 ns/op           0 B/op          0 allocs/op

可以看到，直接存储切片值时，每次断言都会产生24字节的堆分配；而存储指针则无任何分配，性能差距显著。

原因分析 #

差异的核心在于Go的接口值语义和逃逸分析逻辑：

1. 空接口的存储机制
   空接口interface{}存储值类型（比如[]byte）时，会保存该值的完整副本——对于切片来说，就是它的三个核心字段：指向底层数组的指针、长度、容量，总共24字节（64位系统）。从接口断言回[]byte时，需要把这个副本再复制出来。

2. 堆分配的触发原因
   基准测试的循环场景中，编译器无法确定断言得到的切片是否会逃逸到函数外部（比如被其他goroutine引用）。为保证内存安全，编译器会将这个切片结构体分配到堆上，这就是每次操作产生24字节分配的原因。

3. 指针类型的优势
   存储*[]byte指针时，空接口里只保存一个8字节的指针值。断言时只是复制这个指针，不需要额外分配内存——指针本身是小值，且编译器可以确定它的生命周期，不会触发堆分配。

背后的设计考量 #

1. 值语义的安全性
   Go的接口设计坚持值语义，存储值类型时持有副本，修改接口内的值不会影响原始值，避免了意外副作用，保证代码的安全性和可预测性。

2. 逃逸分析的保守策略
   为避免栈溢出风险，Go的逃逸分析对无法确定生命周期的变量采取保守策略，分配到堆上。虽然带来一定性能开销，但换来了内存安全和代码简洁性——开发者无需手动管理内存。

3. 性能与安全的平衡
   指针类型性能更高，但需要开发者手动管理引用，存在空指针风险。Go通过这种设计，在默认的安全值语义和可选的高性能指针之间提供平衡，让开发者可根据场景选择合适方案。

内容的提问来源于stack exchange，提问作者Cooper Yan