用 sync.Pool 复用对象可显著降低 GC 压力，适用于创建开销大、生命周期短、可重置的无状态对象，需手动 Reset 并提供 fallback 创建逻辑，且不可依赖必然命中。

用 sync.Pool 复用对象，而不是每次都 new

Go 的 GC 压力常来自高频分配短生命周期对象，比如 bytes.Buffer、json.Decoder、自定义结构体等。每次 new 或 &T{} 都会触发堆分配，若频率高（如 HTTP 请求中每请求一次），GC 次数和 STW 时间明显上升。

sync.Pool 是 Go 提供的轻量级对象复用机制，适合「创建开销大 + 生命周期短 + 无状态或可重置」的对象：

• 必须在对象归还前清空内部字段（比如 buf.Reset()），否则可能携带上一次请求的脏数据
• Pool 中的对象可能被 GC 清理掉，不能依赖「一定命中」，始终要准备 fallback 创建逻辑
• 不要把含 finalizer 或依赖 goroutine 生命周期的对象放进 Pool（比如未关闭的 http.Client）

var bufferPool = sync.Pool{
	New: func() interface{} {
		return new(bytes.Buffer)
	},
}

func handleRequest() {
	buf := bufferPool.Get().(*bytes.Buffer)
	buf.Reset() // 关键：必须重置
	buf.WriteString("hello")
	// ... use buf
	bufferPool.Put(buf) // 归还，但不保证下次能取到
}

避免隐式堆逃逸：用 go tool compile -gcflags="-m" 看逃逸分析

很多看似栈分配的变量，因被取地址、传入接口、闭包捕获等原因逃逸到堆，导致不必要的 GC 压力。逃逸不是由 new 或 make 决定的，而是编译器根据使用方式判断。

常见逃逸场景：

• 函数返回局部变量的指针（return &x）
• 将局部变量赋值给 interface{} 类型（比如传给 fmt.Println）
• 在闭包中引用外部局部变量
• 切片底层数组过大，且被函数外持有（如返回 make([]byte, 1024) 后直接返回）

执行 go tool compile -gcflags="-m -l" main.go（-l 禁用内联以便更准确定位），关注输出中的 ... escapes to heap 行。重点优化高频路径上的逃逸点。

小对象优先用 struct 而非 pointer，配合值语义传递

对于小于 64 字节、字段少、不常修改的结构体（如 Point、Header、Token），直接按值传递比传 *T 更省 GC 开销——栈拷贝成本低，且避免指针追踪。

但要注意：

• 如果结构体含 slice/map/chan/interface{}，即使很小也会间接导致堆分配
• 方法接收者用值还是指针，不仅看大小，还要看是否需要修改原值；但若纯读取且结构体小，func (t T) Read() 比 func (t *T) Read() 更利于逃逸控制
• RPC 或序列化场

  

  景下，值传递可能引发多次拷贝，需权衡（此时可考虑 unsafe.Slice 或预分配缓冲）

批量处理时预分配切片容量，避免 grow 触发多次堆分配

append 在底层数组满时会调用 growslice，按近似 2 倍扩容并 malloc 新数组，旧数组等待 GC。高频追加（如解析日志行、聚合指标）易产生大量临时垃圾。

解决方式很直接：预估长度，用 make([]T, 0, N) 初始化切片：

• HTTP 中解析 query 参数，已知最多 20 个 key-value，就 make([][2]string, 0, 20)
• 数据库批量查询结果，知道 rows.N()，就 make([]*User, 0, n)
• 不确定上限但有典型值，可用 make([]byte, 0, 1024) 作为起点，避免从 0 开始反复 realloc

注意：make([]T, N) 是初始化长度为 N 的切片（会 zero-initialize），而 make([]T, 0, N) 只是预分配容量，更轻量。

真正难的是识别哪些路径在压测中成为 GC 瓶颈——pprof 的 runtime.MemStats 和 go tool trace 中的 GC events 才是依据。光靠代码模式不能替代实测，尤其当业务逻辑嵌套深、中间件多时，逃逸和分配热点往往藏得深。