go内存优化核心是控制堆分配、避免逃逸：用sync.pool复用对象、预分配切片容量、分析逃逸行为、小结构体优先值传递，聚焦高频路径并结合pprof验证。
Go 程序的内存效率，核心在于控制堆分配、避免不必要的对象创建，并理解编译器如何决定变量是否逃逸。做得好，GC 压力小、延迟低、吞吐高；忽略它，哪怕逻辑正确，也可能在高并发下成为瓶颈。
用 sync.Pool 复用临时对象
频繁创建短生命周期对象（如切片、结构体、缓冲区）是堆压力的主要来源。sync.Pool 提供了安全、无锁的对象复用机制，特别适合处理“用完即弃”但构造成本高的类型。
- 定义一个全局 Pool，New 字段返回初始化后的对象（比如 make([]byte, 0, 1024)）
- 获取时调用 Get()，用完立刻 Put() 回池中——不要在 Put 前修改字段，除非你确保其他 goroutine 不会读到脏数据
- 注意 Pool 中的对象可能被 GC 清理，所以 Get 返回值必须校验或重置，不能直接假设状态干净
- 典型适用场景：http 中间件里的 context.Value 缓存、json 解析用的 bytes.Buffer、日志格式化用的字符串构建器
预分配切片容量，避免多次扩容
切片 append 是常见逃逸源。如果编译器无法在编译期确定最终长度，底层底层数组大概率分配在堆上，且扩容会触发内存拷贝和新分配。
- 已知上限时，用 make([]T, 0, cap) 显式指定容量，比如解析固定字段的 JSON 数组，提前知道最多 16 个元素，就 make([]String, 0, 16)
- 遍历前先 len() 或 cap() 判断，能复用就复用底层数组，例如 for i := range dst { dst[i] = src[i] } 比反复 append 更可控
- 避免在循环内无节制 append，尤其是嵌套循环里——考虑外层预分配 + 索引赋值替代
借助 go build -gcflags=”-m” 看清逃逸行为
逃逸分析是 Go 编译器自动做的决策：变量是否必须在堆上分配（因为生命周期超出当前函数、被闭包捕获、或地址被传给未知函数）。不理解它，就很难真正控住分配。
- 加 -m 输出基础逃逸信息，-m=2 显示更详细路径（比如哪一行导致了逃逸）
- 常见逃逸诱因：将局部变量取地址后传参（尤其接口参数）、返回局部变量指针、把变量赋给 interface{} 或 map[string]Interface{}、在 defer 中引用局部变量
- 不是所有逃逸都该消除——有时为了可读性或设计清晰，接受少量堆分配更合理；重点应放在高频路径（如请求处理主干、热点循环）上
用结构体代替指针，栈上分配更可靠
小结构体（通常小于数个机器字长，如 32–64 字节）按值传递不仅开销小，而且更容易留在栈上，减少 GC 跟踪负担。
- 避免对小结构体盲目加 *，比如 type Point Struct{ X, Y int }，传 Point 比 *Point 更轻量，也更利于内联和逃逸优化
- 方法接收者也优先用值类型，除非结构体大（>128 字节）或明确需要修改原值
- 如果结构体含 slice/map/chan/func/interface，它本身仍可能逃逸，因为这些字段本质是指针——这时关注字段内容比关注结构体本身更重要
内存优化不是越激进越好，而是在可观测、可验证的前提下，聚焦真实瓶颈。从 pprof 查 heap profile 找 top 分配者，再结合逃逸分析定位根因，比凭经验瞎猜高效得多。