Go内存管理需主动干预：预分配切片cap、用sync.Pool复用短命对象、规避逃逸、定制LRU缓存策略，否则高频分配将抬高GC频率拖慢吞吐。
Go 的内存管理不是“交给 GC 就完事”，而是需要你主动干预分配模式、对象生命周期和数据结构选择。不干预，高频 append、make、缓存项创建会直接抬高 GC 频率，拖慢吞吐。
预分配切片 cap 而非只设 len
这是最常被忽略的性能点：只调用 make([]T, 0) 等于 cap=0，第一次 append 就触发底层数组分配；后续扩容还伴随 memcpy。尤其在循环中累积追加时，开销呈指数级增长。
- 知道最终长度？直接
make([]int, 0, estimatedCount) - 不确定但有上限？按上限预分配，比如日志批量写入最多 1000 条：
entries := make([]*LogEntry, 0, 1000) - 避免用
[]string{}初始化后再append——它等价于make([]string, 0)，没省事
用 sync.Pool 复用高频短命对象
sync.Pool 不是万能胶，它只适合“创建成本高 + 生命周期短 + 可复用”的对象，比如 *bytes.Buffer、HTTP 中间件里的临时结构体、序列化用的 json.Encoder 实例。
- 对象必须可安全重置：获取后要清空状态（如调用
b.Reset()），否则残留数据会污染后续使用 - 不要存大对象（> 1MB）或带外部引用的对象（如含未关闭文件句柄的 struct），Pool 不保证回收时机，易导致内存滞留
- 典型误用：把
http.Request或context.Context放进 Pool——它们由 runtime 管理，且含不可复用字段
规避逃逸：让小对象留在栈上
变量逃逸到堆，不仅增加 GC 压力，还降低 CPU 缓存局部性。用 go build -gcflags "-m" 查看逃逸分析结果，重点关注标有 ... escapes to heap 的行。
立即学习“go语言免费学习笔记（深入）”；
- 函数返回局部变量地址？必然逃逸（如
return &x） - 传指针给接口方法？若接口方法签名含指针参数（如
io.Writer.Write([]byte)），[]byte很可能逃逸 - 闭包捕获大变量？缩小捕获范围，或改用显式参数传递
- 注意：Go 1.22+ 对小数组（≤ 128 字节）做了栈优化，但别依赖——实测为准
LRU 缓存等高频结构要定制内存策略
像 golang-lru 这类库，默认每次 Add 都 new 一个 Entry，高并发下就是 GC 发射器。不能只靠 “用了 LRU 就高效” 的错觉。
- 预设容量：
lru.New(5000)比lru.New(0)少 90%+ 的链表节点分配 - 复用 Entry：自己实现
EntryPool，Get 时重置next/prev/key/value字段再 Put 回池 - 慎用
OnEvicted回调：如果回调里又分配新对象（如记录日志用fmt.Sprintf），等于在 GC 触发点上再加压
真正难的不是记住这些技巧，而是在 profile 数据出来前就预判哪条路径会分配、逃逸或阻塞；更难的是，当 pprof allocs 显示某函数占 40% 分配量时，你能立刻定位到是那个没设 cap 的切片，还是池里忘了 Reset 的 Buffer。
