Go指针本身不触发GC，但只要可达就阻止回收；逃逸分析决定变量分配在栈或堆；主动断开引用、避免CGO悬空指针是内存管理关键。
Go 的指针本身不触发垃圾回收（GC），但只要它还“被某个根对象能触达”，指向的值就永远不会被 GC 回收——理解这点，就抓住了内存管理的核心。
为什么返回局部变量指针不会崩溃？逃逸分析在背后干活
很多人以为 return &x 是危险操作，但在 Go 里它通常安全。原因不是 GC 特别聪明，而是编译器提前做了逃逸分析：一旦发现局部变量地址可能“逃出”当前函数作用域（比如被返回、存入全局 map、发到 chan），就会自动把它分配到堆上，交由 GC 管理。
- 不逃逸：小结构体、短生命周期、仅在栈内使用的变量 → 分配在栈，函数返回即销毁
- 逃逸：被指针暴露出去的对象 → 分配在堆，存活期由 GC 根据可达性决定
- 验证方式：
go build -gcflags="-m" main.go查看逃逸报告
指针长期持有 = 内存无法释放，典型泄漏场景
GC 只看“是否可达”，不看“是否还在用”。只要一个指针还挂在全局变量、缓存、channel 或 goroutine 的闭包里，它指向的整块数据（包括其字段引用的其他对象）就一直活在堆上。
- 全局
var cache = make(map[string]*BigStruct)：忘了delete(cache, key)→ 对象永远不回收 - goroutine 中启动定时任务，闭包捕获了大对象
data：即使主逻辑已结束，data仍被闭包隐式持有 - 链表节点互相引用（
a.next = b; b.prev = a），又把a存进全局sync.Map→ 整个环都活下来
如何帮 GC 尽早识别“该收了”？主动断开是关键
Go 不支持手动 free，但你可以主动切断引用路径，让对象更快变成“不可达”。这不是强制释放，而是给 GC 提供清晰信号。
立即学习“go语言免费学习笔记（深入）”；
- 从全局容器中移除对象后，顺手将它的指针字段置为
nil（尤其对含反向指针的结构体） - goroutine 结束前，清空对大缓冲区的引用：
buf = nil - 使用
sync.Pool复用对象时，Put前重置内部指针字段，避免旧引用滞留 - 避免在
defer中做耗时操作并持有指针，defer 函数执行前对象一直算“活跃”
CGO 场景下指针最危险：GC 完全看不见 C 侧引用
这是最容易被忽略的致命坑。当你把 Go 分配的结构体指针传给 C 库（比如 C.some_init(&s)），Go GC 并不知道 C 还在用它。只要 Go 代码里没其他变量持有着 &s，GC 下次运行就可能回收那块内存，C 侧拿到的就是悬空指针。
- 正确做法：用
C.Cmalloc或C.CString在 C 堆分配内存；或用runtime.KeepAlive(s)延长 Go 对象生命周期 - 更稳妥：用
unsafe.Pointer+runtime.Pinner（Go 1.22+）显式固定对象，防止 GC 移动或回收 - 调试线索：C 侧读到随机值、
nil函数指针、SIGSEGV —— 先查 GC 是否提前回收了你传过去的 Go 内存
真正难的不是写对语法，而是在设计阶段就想清楚“谁持有这个指针、它什么时候才算不用了”。GC 很可靠，但它只认引用，不认语义。
