Go内存分配由编译器通过逃逸分析自动决定：不逃逸的变量栈分配，快且自动回收；逃逸的变量堆分配，需GC管理；开发者应减少不必要的逃逸以降低GC压力。
Go 语言的内存分配看似简单，实则由编译器在编译期通过逃逸分析（escape analysis）自动决定变量该放在栈上还是堆上——开发者不显式控制 new/malloc，但理解其机制对写出高效、低 GC 压力的代码至关重要。
栈分配：快、轻量、自动回收
局部变量（如函数内声明的 int、string 字面量、小结构体等）只要被判定为“不会逃逸”，就直接分配在栈上。栈内存由 goroutine 私有管理，函数返回时整块栈帧自动弹出，零开销回收。
典型栈分配场景：
- 值类型变量且生命周期严格限定在当前函数内（如 var x int = 42）
- 小数组（如 [4]int）、短字符串字面量（如 "hello"）
- 结构体字段全为栈友好类型，且未取地址传给外部作用域
堆分配：跨函数、长生命周期、需 GC 管理
一旦变量“逃逸”出当前函数作用域（例如被返回、赋值给全局变量、传入 goroutine、或被接口/切片/映射间接持有），编译器就会将其分配到堆上。堆内存由运行时统一管理，依赖垃圾回收器（GC）异步回收。
立即学习“go语言免费学习笔记（深入）”；
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
常见逃逸触发点：
- 函数返回局部变量的指针（return &x）
- 将局部变量赋值给全局变量或包级变量
- 启动新 goroutine 并传入局部变量地址（go f(&x)）
- 将变量作为 interface{} 类型使用（如传给 fmt.Println）
- 切片底层数组扩容后原地无法容纳，需在堆上分配更大空间
逃逸分析：编译器的静态决策过程
Go 编译器（gc）在编译阶段进行逃逸分析，不运行程序就能判断每个变量的内存归属。它基于数据流和作用域规则做保守推断：只要存在任何可能让变量在函数返回后仍被访问的路径，就视为逃逸。
查看逃逸分析结果的方法：
- 加 -gcflags="-m" 编译：显示每行变量是否逃逸（如 moved to heap）
- 加 -gcflags="-m -m" 查看更详细分析过程（含原因）
- 注意：开启内联（默认开启）会影响逃逸结果，可加 -gcflags="-m -l" 禁用内联辅助诊断
写代码时的关键意识
逃逸不是 bug，但高频堆分配会增加 GC 压力与内存占用。优化方向不是“避免一切逃逸”，而是减少不必要的逃逸：
- 优先使用值语义（如 struct 而非 *struct），尤其当结构体较小且不需共享修改时
- 避免在热路径中将局部变量转成 interface{}（如日志中传大量临时 struct）
- 切片操作尽量复用底层数组（预分配容量、避免频繁 append 导致扩容）
- 返回结构体而非指针，除非明确需要共享状态或结构体过大（>8KB 可考虑指针）
