sync.pool可复用临时对象以减轻gc压力，适用于http缓冲区等短生命周期场景，但需重置状态且不保证复用；优先栈分配、预分配切片容量、慎用interface和反射。
用 sync.Pool 复用临时对象，避免高频分配
频繁创建短生命周期对象（如 []byte、strings.Builder、自定义结构体）是 GC 压力的主要来源。Go 的 sync.Pool 能让 goroutine 本地复用对象，跳过堆分配和后续回收。
- 适用场景：HTTP handler 中每次请求都 new 的缓冲区、JSON 解析器、日志字段容器等
- 注意
sync.Pool不保证对象一定被复用，也不保证对象存活时间，不能用于需要严格生命周期控制的场景 - 务必在
Put前重置对象状态（如清空slice的len，但保留cap；调用strings.Builder.Reset()），否则可能引发数据污染或 panic - 池中对象可能被 GC 清理，所以
Get后必须判空并做兜底初始化
var bufPool = sync.Pool{
New: func() interface{} {
return make([]byte, 0, 1024)
},
}
func handleRequest() {
buf := bufPool.Get().([]byte)
defer bufPool.Put(buf) // 注意：必须确保 Put 在函数退出前执行
buf = buf[:0] // 重置 len，保留 cap
buf = append(buf, "hello"...)
// ... use buf
}
优先使用栈分配，避免逃逸到堆
Go 编译器会自动将不逃逸的对象分配在栈上，零成本回收。一旦变量“逃逸”，就会被分配到堆，触发 GC 跟踪与清扫。
- 用
go build -gcflags="-m -l"查看逃逸分析结果，重点关注 “moved to heap” 提示 - 常见逃逸原因：返回局部变量地址、传入接口类型参数（如
fmt.Println(s)中的字符串可能逃逸）、闭包捕获大变量、切片扩容后超出原始栈空间 - 避免对小结构体取地址传参；用值传递代替指针传递，除非结构体 > 128B 或明确需要修改原值
- 对已知长度的小数组（如
[16]byte），直接声明而非用make([]byte, 16)，前者栈分配，后者堆分配
预分配切片容量，防止多次扩容拷贝与内存浪费
append 触发扩容时，不仅消耗 CPU 拷贝旧数据，还会多分配内存（通常 1.25–2 倍），造成碎片和 GC 负担。
- 若长度可预估（如解析固定字段 JSON、读取已知大小的文件块），用
make([]T, 0, N)显式指定cap - 避免反复
append单个元素后取res[:]——这无法避免中间扩容；改用预分配 + 索引赋值 - 注意：过度预分配（如
cap=1MB）虽减少扩容，但可能长期占用内存不释放，需权衡
type Record struct{ ID int; Name string }
// ❌ 高频扩容
var records []Record
for _, id := range ids {
records = append(records, Record{ID: id})
}
// ✅ 预分配
records := make([]Record, 0, len(ids))
for _, id := range ids {
records = append(records, Record{ID: id})
}
慎用 interface{} 和反射，它们隐式触发堆分配
很多看似无害的操作，底层会因类型擦除或动态方法查找而分配内存，比如 fmt.Sprintf、json.Marshal、errors.New 返回的 error 接口值。
立即学习“go语言免费学习笔记（深入）”；
-
fmt.Sprintf("%d", n)必然分配新字符串；若只是拼接数字，用strconv.AppendInt直接写入预分配的[]byte -
json.Marshal对 map/slice 默认分配新字节切片；若需反复序列化同类结构，考虑预分配bytes.Buffer并复用 - 避免在热路径中用
reflect.ValueOf或reflect.TypeOf；它们返回的reflect.Value是接口类型，且内部有堆分配 - 用泛型替代部分反射逻辑（Go 1.18+），编译期单态化，零额外分配
strings.Builder 初始化、2 次 map[string]string 构造、1 次 fmt.Sprintf，单独看都不起眼，合起来就让每秒千次请求产生数 MB 堆分配。逐个定位、逐个替换，比盲目加 sync.Pool 更有效。 
