用 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 决定的，而是编译器根据使用方式判断。
常见逃逸场景：
立即学习“go语言免费学习笔记（深入）”；
- 函数返回局部变量的指针（
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 才是依据。光靠代码模式不能替代实测，尤其当业务逻辑嵌套深、中间件多时，逃逸和分配热点往往藏得深。
