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 接口值。

• fmt.Sprintf("%d", n) 必然分配新字符串；若只是拼接数字，用 strconv.AppendInt 直接写入预分配的 []byte
• json.Marshal 对 map/slice 默认分配新字节切片；若需反复序列化同类结构，考虑预分配 bytes.Buffer 并复用
• 避免在热路径中用 reflect.ValueOf 或 reflect.TypeOf；它们返回的 reflect.Value 是接口类型，且内部有堆分配
• 用泛型替代部分反射逻辑（Go 1.18+），编译期单态化，零额外分配

实际优化中，最易被忽略的是：**GC 压力往往不是单点问题，而是多个小分配叠加的结果**。比如一个 HTTP handler 里同时做了 3 次 strings.Builder 初始化、2 次 map[string]string 构造、1 次 fmt.Sprintf，单独看都不起眼，合起来就让每秒千次请求产生数 MB 堆分配。逐个定位、逐个替换，比盲目加 sync.Pool 更有效。