go中对象生命周期由逃逸分析决定：未逃逸的栈上对象函数返回即销毁，逃逸到堆的对象才受gc管理；new和make不直接决定分配位置，而取决于编译期逃逸分析结果。
Go 里对象的生命周期不取决于你写了 new 还是 make，而取决于它是否“逃逸”——编译器在编译期就决定了它该放在栈上还是堆上。逃逸的对象才真正进入 GC 管理范围；没逃逸的，函数一返回就没了，连 GC 都不参与。
怎么判断一个变量会不会逃逸到堆上
逃逸分析是 Go 编译器的静态分析过程，不运行代码就能知道内存去向。常见逃逸场景包括：
- 变量地址被返回（如
return &x） - 赋值给全局变量或包级变量
- 作为参数传给不确定是否保留引用的函数（比如
fmt.Println、append切片时扩容、传入interface{}） - 闭包中捕获了局部变量，且该闭包在函数返回后仍可能执行
- 切片底层数组过大（>64KB）或长度/容量在编译期无法确定
验证方式：用 go build -gcflags="-m -l" 编译，看输出里有没有 ... escapes to heap。加 -l 是禁用内联，避免干扰判断。
new 和 make 的分配行为差异
这两个函数都分配内存，但语义和逃逸倾向完全不同：
-
new(T)总是分配零值内存并返回*T，但分配位置仍由逃逸分析决定——如果返回的指针没逃逸，实际内存仍在栈上（只是编译器帮你取了地址） -
make([]T, n)或make(map[T]U)创建的是“值”，不是指针；但切片/映射/通道的底层数据结构（如底层数组、哈希表桶）几乎必然逃逸到堆上，因为它们大小动态、生命周期常超出当前函数 - 不要误以为
make= 堆分配 —— 它创建的 header 结构（slice header、map header）本身很小，可能留在栈上；真正堆分配的是其指向的底层数据
示例：s := make([]int, 10) 中，slice header 在栈，10 个 int 的数组在堆；而 s := make([]int, 2) 在某些版本中甚至可能全栈分配（取决于逃逸分析结果和 size cutoff）。
对象释放不是靠“手动”，而是靠“不可达”
Go 没有 free 或 delete（除 delete(map, key) 这种特定操作），释放完全依赖 GC 标记-清除。关键点在于：
- 只要存在任意一条从根对象（goroutine 栈、全局变量、寄存器等）可达的引用链，对象就不会被回收
- 常见的“假泄漏”：把指针存进全局 map 但忘了删；往 channel 发送后没消费，sender goroutine 卡住持有着引用；defer 中闭包捕获了大对象
- GC 不保证立即回收——它只保证“最终”回收。高频率小对象分配会抬高 GC 压力，表现为
runtime.MemStats.NextGC提前触发
调试技巧：用 runtime.ReadMemStats 观察 HeapAlloc 和 HeapInuse 变化；用 pprof 的 heap profile 查看哪些类型占堆最多。
最易被忽略的一点：栈上对象根本不在 GC 视野里，所以优化重点不是“怎么释放”，而是“怎么让它别逃逸”。写代码时多看 -gcflags="-m" 输出，比调 GC 参数实在得多。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
