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 提供清晰信号。

• 从全局容器中移除对象后，顺手将它的指针字段置为 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 很可靠，但它只认引用，不认语义。