Go GC优化核心是让分配更可预测、集中、少冗余：用sync.Pool复用临时对象并重置状态；通过逃逸分析控制变量栈分配；预分配slice/map容量避免扩容碎片；合并结构、用数组替代切片减少小对象堆积。
Go 的 GC（垃圾回收）虽然自动高效，但频繁分配小对象、逃逸到堆、或过度依赖运行时分配，仍会显著增加 GC 频次和内存碎片，拖慢响应、抬高延迟。优化核心不是“不用堆”，而是“让分配更可预测、更集中、更少冗余”。
复用对象：用 sync.Pool 管理高频临时对象
对生命周期短、构造开销大、且类型固定的临时对象（如 JSON 编码器、bytes.Buffer、自定义结构体），sync.Pool 能有效避免重复分配与释放。
关键点：
- Pool 不保证对象一定复用，也不保证线程安全地“独占”，需在 Get 后重置状态（如 buffer.Reset()、struct 字段清零）
- 避免将含 finalizer 或依赖外部资源的对象放入 Pool
- 示例：复用 bytes.Buffer 编码 HTTP 响应
func handle(w http.ResponseWriter, r *http.Request) {
buf := bufPool.Get().(*bytes.Buffer)
buf.Reset() // 必须清空
json.NewEncoder(buf).Encode(data)
w.Write(buf.Bytes())
bufPool.Put(buf) // 放回池中
}
控制逃逸：让变量留在栈上
Go 编译器根据逃逸分析决定变量分配位置。栈分配无 GC 开销、速度快、无碎片。可通过 go build -gcflags="-m" 查看逃逸原因。
立即学习“go语言免费学习笔记（深入）”；
常见导致逃逸的操作：
- 取局部变量地址并返回（如 return &x）
- 将局部变量赋值给接口类型（尤其空接口 interface{}）
- 向 map/slice 中写入局部变量的指针
- 闭包捕获了局部变量的地址
改进建议：优先传值而非指针（尤其小结构体）；用具名类型替代 interface{}；拆分大函数减少变量作用域；必要时用 go tool compile -S 查看汇编确认是否逃逸。
预分配容量：避免 slice/map 动态扩容
slice append 和 map 插入若未预估大小，会触发多次底层数组/桶的 realloc，不仅耗时，还会留下旧内存块成为碎片，加剧 GC 扫描压力。
实践方式：
- 创建 slice 时用 make([]T, 0, expectedCap)，而非 []T{} 或 make([]T, 0)
- 初始化 map 时指定容量：make(map[K]V, expectedSize)
- 处理已知长度的数据（如解析固定字段 JSON、读取文件行数确定）时，直接预分配
例如解析 1000 条日志，不要循环 append 到空 slice，而用 logs := make([]*Log, 0, 1000)。
减少小对象堆积：合并结构、使用数组替代切片
大量
可行策略：
- 将多个关联小字段打包进一个结构体，降低分配次数（如用 [4]uint64 替代 4 个 uint64 变量）
- 对固定数量元素，优先用数组 [N]T 而非 []T —— 数组是值类型，栈分配更可控
- 用位操作或整数字段代替多个布尔字段（如用 uint32 的 bit 位表示 32 个 flag）
注意：优化要基于 profile 数据（如 pprof heap profile），避免过早或过度设计。
