手动调用 runtime.GC() 会破坏 Go 并发 GC 的自动节奏，引发更频繁的 GC 周期甚至“雪崩”，且无法降低堆占用；应监控 HeapAlloc/NextGC 比值并合理设置 GOGC。
为什么 runtime.GC() 不能缓解 GC 压力
手动调用 runtime.GC() 不仅不减压，反而常引发更频繁的 GC 周期。Go 的 GC 是并发、三色标记式，它根据堆增长速率自动触发；强行触发会打断正常节奏，导致后续更短间隔内再次触发，尤其在高分配场景下形成“GC 雪崩”。
常见错误现象：pprof 显示 GC 频次突增、gctrace=1 输出里 gc N @X.xs X%: ... 行密集出现，但堆实际没明显下降。
- 别在循环或请求处理中调用
runtime.GC() - 监控真正指标：用
runtime.ReadMemStats()查NextGC和HeapAlloc比值，比值持续 >0.8 才说明堆逼近目标 - 临时缓解可设
GOGC=200（默认 100），但这是权衡——延后 GC 意味着单次停顿可能略长，且只对堆有效，不影响栈对象
切片预分配最常被忽略的两个地方
切片追加（append）触发底层数组扩容时，旧数组若仍有引用，就无法被回收——这是 GC 压力的隐性大户。预分配不是“多 alloc 一点”，而是让容量精准匹配最终大小，避免中间多次复制和残留引用。
使用场景：解析 JSON 数组、读取文件行、批量 DB 查询结果收集。
立即学习“go语言免费学习笔记（深入）”；
-
make([]int, 0, n)比make([]int, n)更安全：前者初始长度为 0，不会意外写入零值占位；后者若未填满，整块内存都算活跃对象 - 从
io.Reader读取时，别用bytes.Buffer.String()后再strings.Split——这会额外生成一个字符串副本和多个子字符串头；改用bufio.Scanner或预分配[]byte+bytes.Split - HTTP handler 中返回 JSON，用
json.NewEncoder(w).Encode(data)，别先json.Marshal成[]byte再写——后者多一次堆分配
sync.Pool 不是缓存，是对象复用开关
sync.Pool 的核心价值不是减少分配次数，而是让短期对象绕过 GC 标记阶段——它管理的是“刚死、还没被扫”的对象。一旦 Pool 中的对象闲置超 2 分钟（或下次 GC 开始），就会被全部清空。
容易踩的坑：把带状态的结构体（如含未关闭的 io.ReadCloser）放 Pool 里复用，下次取出时直接 panic。
- 适合放：
[]byte缓冲区、bytes.Buffer、临时正则*regexp.Regexp（需确保无全局副作用） - 不适合放：含指针字段且生命周期不确定的 struct、任何需要显式 Close 的资源
- 必须配对使用：
Get()后要检查是否为nil，Put()前要重置状态（比如buf.Reset()），否则残留数据会污染下次使用
逃逸分析输出里最该盯住的三行
go build -gcflags="-m -l" 输出中，真正影响 GC 压力的是那些“moved to heap”提示——它们告诉你本可在栈上分配的对象，因何原因被迫上堆。
性能影响：栈分配近乎免费；堆分配需原子操作+可能触发 GC；且栈对象函数返回即销毁，堆对象得等标记清除。
-
... escapes to heap：变量地址被返回、传给 goroutine、或赋给接口类型（如interface{}、error） -
... does not escape：安全，优先保留 - 最隐蔽的是闭包捕获：匿名函数里用了外部变量，整个变量升为堆分配——改用参数传入，或拆成纯函数
复杂点在于：有些逃逸不可避免（比如 HTTP handler 必须返回 http.HandlerFunc 接口），这时重点应转向控制逃逸对象的大小和生命周期，而不是强求不逃逸。
