Go GC压力源于堆对象过多、碎片化、生命周期短；优化核心是减少逃逸，优先栈分配，善用sync.Pool复用对象，并预分配切片容量、用strings.Builder拼接字符串。
Go 的 GC 压力不是靠多调用 runtime.GC() 缓解的，而是源于「堆上对象太多、太碎、生命周期太短」。优化核心就一条：让对象别上堆，或者上了堆也别总新建。
怎么判断对象是不是逃逸到堆了
编译器决定变量在栈还是堆，不看你写没写 &，而看它“能不能被函数外访问”。最常见的误判是以为 &MyStruct{} 和 new(MyStruct) 一样——其实前者可能栈分配，后者一定堆分配。
- 用
go build -gcflags="-m -l"查看逃逸分析结果，重点找escapes to heap - 只要把局部变量地址赋给全局变量、传进
interface{}（比如fmt.Println(x)）、或作为返回值且接收方类型模糊，基本就逃逸 - 结构体里只要有一个字段是指针（哪怕
name *string），整个结构体逃逸概率飙升；字段顺序也有影响，指针字段尽量往后放 - 闭包捕获大变量（如切片、map）会拖整个栈帧上堆，比你想象中更容易发生
sync.Pool 不是缓存，是“临时借还”
sync.Pool 不是对象长期存放地，它只对「高频创建 + 短期存活 + 大小适中」的对象有效。用错反而引入竞态或内存污染。
-
New函数必须每次返回全新对象，不能复用全局实例（否则并发Get会读写同一块内存） -
Put前必须确保对象已完全退出作用域——不能还在 channel 里、没关的 goroutine 里、或闭包中引用着 - 每次
Get可能返回nil，务必检查并初始化；Put前必须重置所有字段（buf.Reset()、slice = slice[:0]） - 池中对象会在 GC 时被清空，也可能在 P 空闲时被提前回收（Go 1.19+ 更激进），别指望它永远有货
示例：var bufPool = sync.Pool{New: func() interface{} { return &bytes.Buffer{} }}，使用时先 b := bufPool.Get().(*bytes.Buffer); b.Reset()，最后 bufPool.Put(b)。
立即学习“go语言免费学习笔记（深入）”；
切片和字符串拼接，别让底层数组反复 malloc
频繁 make([]byte, n) 或用 + 拼字符串，本质是不断申请新底层数组，旧的等 GC 扫——但扫描本身就有开销。
- 预分配容量：用
make([]byte, 0, 1024)而非make([]byte, 1024)，后续append不触发扩容 - 复用切片：用
slice = slice[:0]清空，保留底层数组；若长期膨胀又很少收缩，需周期性重建防内存滞留 - 字符串拼接优先用
strings.Builder，调用Grow()预估大小，避免内部多次grow - 避免在热路径（如 HTTP handler）里解析成
map[string]interface{}，改用结构体 +json.RawMessage延迟解析
真正难的不是知道该怎么做，而是识别哪些变量本该在栈上却悄悄逃逸了——尤其当它藏在日志、中间件、或第三方库调用链里时。一次 gctrace=1 观察 scanned 字节数是否逐轮上涨，往往比读十遍文档更快定位问题。
