少分配才快：逃逸分析、栈与堆、对象复用

“返回指针一定逃逸”“用了 new 就在堆上”都不准确。Go 编译器根据值的生命周期和使用方式决定放在栈还是堆；源码写法只是输入，逃逸分析结果才是证据。

编译器在回答生命周期问题

    flowchart TD
    V["创建一个值"] --> K{"编译器能证明它不越过当前栈帧吗？"}
    K -->|能| S["栈或寄存器"]
    K -->|不能| H["堆"]
    S --> R["函数返回后栈空间可复用"]
    H --> G["由 GC 跟踪和回收"]
  

func newUser() *User {
	u := User{Name: "yanlong"}
	return &u
}

这段代码里的 u 可能逃逸，但调用被内联后，编译器也可能把最终对象留在调用方栈上。逃逸分析是跨函数、受内联和版本影响的优化，不是语言语义。正确性不能依赖一个值当前恰好分配在哪里。

让编译器告诉你

go test -gcflags='all=-m=2' ./internal/parser 2>&1
go build -gcflags='all=-m=2' ./cmd/app 2>&1

输出中的 escapes to heap、moved to heap 和 leaking param 能解释路径，但全量依赖会很嘈杂。先定位目标包和函数，再结合 benchmark 的分配指标验证影响：

func BenchmarkEncode(b *testing.B) {
	u := User{ID: 42, Name: "yanlong"}
	b.ReportAllocs()
	for b.Loop() {
		Sink = Encode(u)
	}
}

go test -bench=BenchmarkEncode -benchmem -count=10 ./internal/codec

allocs/op 比一次编译输出更接近最终问题，但也要防止编译器消除无用工作，并把 fixture 构造放在计时循环外。

常见分配来源

容器扩容

已知上限时预分配容量，避免反复复制：

out := make([]Result, 0, len(inputs))
for _, in := range inputs { out = append(out, transform(in)) }

这不是让容量越大越好。过度预分配会直接增加堆占用，并让大底层数组因一个小切片而长期存活。

字符串和字节切换

string(b)、[]byte(s) 通常涉及复制。先确认转换是否在热点，并优先重构 API，让同一种表示贯穿调用链。用 unsafe 消除复制会把不可变性和生命周期风险带进来，通常不是第一选择。

接口、闭包和可变参数

把具体值装入接口不必然分配，但在值需要被装箱并越过当前作用域时可能逃逸。捕获局部变量的闭包、启动 goroutine、把指针存入全局或堆对象，也会延长生命周期。判断仍应看编译器和 profile，而不是背规则。

大小运行时才知道的对象

动态大小的切片底层数组通常在堆上。Go 1.26 改进了一部分可变大小切片的栈分配，但这是优化机会，不是承诺；代码仍应按堆分配也正确来写。

减少分配的优先级

    flowchart LR
    P["Profile 找到热点"] --> O["减少工作量 / 改算法"]
    O --> A["预分配与批处理"]
    A --> C["调整 API，减少转换和临时对象"]
    C --> U["谨慎复用对象"]
  

一次数据库调用通常比几次小分配昂贵得多。先优化请求次数、算法和序列化路径，再处理对象生命周期。减少分配的收益来自降低分配器与 GC 工作，不是“堆一定比栈访问慢”这么简单。

sync.Pool 不是通用缓存

Pool 适合多个 goroutine 共享、创建成本较高、可重复使用的临时对象，例如编码缓冲区。池内对象可能随时被运行时移除，不能承载连接、会话或必须存在的状态。

var buffers = sync.Pool{New: func() any { return new(bytes.Buffer) }}

func encode(v any) ([]byte, error) {
	b := buffers.Get().(*bytes.Buffer)
	b.Reset()
	defer func() {
		if b.Cap() <= 64<<10 { buffers.Put(b) } // 不把异常大缓冲长期留池
	}()

	if err := json.NewEncoder(b).Encode(v); err != nil { return nil, err }
	return bytes.Clone(b.Bytes()), nil // 返回值不能继续引用即将复用的缓冲区
}

复用最危险的是所有权：对象放回池后，任何旧引用都不能再读写。还要清空敏感数据，控制大对象滞留，并用 benchmark 证明 Pool 确实改善吞吐或 GC，而非只让代码复杂。

看整体，而不是追求零分配

GC 成本与存活堆、分配速率和扫描量有关。某些分配让所有权清晰、代码安全，完全值得保留。优化闭环应是：代表性 benchmark → CPU/内存 profile → 逃逸输出解释 → 小改动 → benchstat 比较 → 线上指标验证。

进一步阅读：Go GC 指南、Diagnostics。