Go内存分配由运行时管理，开发者应通过逃逸分析优化：变量若逃逸出函数作用域则堆分配，否则栈分配；优先栈上创建小对象、复用切片底层数组、使用sync.Pool减少GC压力。
Go 语言的内存分配由运行时自动管理，但开发者仍可通过理解栈与堆的行为、结合逃逸分析（escape analysis）来主动优化内存使用。关键不在于“避免堆分配”，而在于让变量在生命周期结束后能被及时回收，减少 GC 压力和分配开销。
理解逃逸分析：编译期决定分配位置
Go 编译器会通过逃逸分析判断一个变量是否必须分配在堆上。若变量的地址被“逃逸”出当前函数作用域（如返回指针、传入 goroutine、赋值给全局变量等），它就会被分配到堆；否则默认在栈上分配。
- 用 go build -gcflags="-m -l" 查看逃逸详情，例如：
./main.go:12:2: &x escapes to heap - -l 禁用内联，让逃逸分析更清晰；生产构建可去掉该参数
- 注意：栈分配 ≠ 零成本（栈空间有限，过大结构仍可能触发栈扩容）
减少不必要的堆分配：小对象优先栈上创建
结构体、切片头、接口值本身很小，但它们背后的数据（如 slice 底层数组、map 哈希表、大 struct 字段）是否堆分配，取决于其生命周期和引用方式。
- 避免直接返回局部变量的地址，改用值传递（尤其对 ≤ 24 字节的小结构体）
- 切片操作（
s[1:5]）不分配新底层数组，只复制 slice header（栈上）；但append可能触发底层数组重分配（堆上） - 用 sync.Pool 复用临时对象（如 JSON 解析中的
bytes.Buffer或自定义结构体），避免高频堆分配
合理使用切片和映射：控制底层数组生命周期
slice 和 map 是引用类型，但 header 本身是值类型。频繁创建 slice 变量开销极小，真正影响性能的是底层数组的分配与复制。
- 预估容量：用
make([]T, 0, expectedCap)减少append过程中的多次扩容 - 复用底层数组：通过
s = s[:0]重置长度，保留容量，避免重复分配 - map 不支持预设 bucket 数量，但小规模场景可考虑用结构体数组 + 线性查找替代
警惕隐式堆分配：闭包、方法值与接口
一些看似轻量的操作会因捕获变量或类型转换导致逃逸。
- 闭包中引用外部变量 → 整个变量逃逸到堆（即使只读）
- 将方法绑定为函数值（如
obj.Method）→ 若方法接收者是大结构体指针，可能触发逃逸 - 将具体类型赋给接口（如
var i fmt.Stringer = myStruct{...}）→ 若结构体较大，整个值会被拷贝到堆上实现接口
