Go中指针生命周期由GC自动管理，不需手动释放；悬空指针常见于返回局部变量地址（编译器逃逸分析通常避免）、切片重分配后旧指针访问、unsafe.Pointer绕过GC跟踪等场景。
Go 中的指针不归你管生命周期
Go 没有手动释放指针或 free 概念，所有指针指向的变量生命周期由垃圾回收器（GC）自动决定。你不能、也不该试图“管理”指针本身的生命周期——真正要理解的是：指针值何时有效、它指向的内存何时还存在、以及哪些操作会让指针悬空。
什么时候指针会变成悬空（dangling）？
悬空指针不是 Go 的运行时错误（不会 panic），但读写它会导致未定义行为（比如读到旧值、0 值，或触发 GC 后的随机数据）。常见场景：
- 返回局部变量的地址：
func bad() *int { x := 42; return &x }——x在函数返回后即不可访问，但 Go 编译器会自动将x抬升（escape）到堆上，所以这个例子实际不会悬空；但若你在for循环里反复取同一个局部变量地址（如&arr[i]），而循环变量本身是栈上复用的，就可能出问题 - 切片或 map 的底层数据被重新分配后，旧指针仍指向原内存块（已失效）——例如：
s := []int{1,2,3}; p := &s[0]; s = append(s, 4); fmt.Println(*p)，此时*p可能仍打印1，也可能打印乱值，取决于是否发生底层数组重分配 - 使用
unsafe.Pointer强转并绕过类型系统时，完全脱离 GC 跟踪，极易悬空（比如把*T转成uintptr存太久，中间 T 对象被回收）
如何安全地持有和传递指针？
核心原则：让 GC 知道对象还在被引用。只要至少有一个活跃的 Go 指针指向某块内存，GC 就不会回收它。
- 优先用普通指针（
*T），避免unsafe.Pointer—— 前者可被 GC 正确扫描，后者不会 - 不要把指针存进 C 内存（如
C.malloc分配的空间）并长期持有，除非你用runtime.KeepAlive显式延长 Go 对象生命周期 - 在闭包中捕获指针变量时，注意逃逸分析：如果闭包逃逸到堆，它持有的指针也会被 GC 跟踪；但如果闭包没逃逸，而它引用的变量又没逃逸，那整个链路都在栈上，返回后即失效
- 用
pprof或go tool compile -gcflags="-m"观察变量是否逃逸 —— 这比猜更可靠
一个容易被忽略的陷阱：sync.Pool 中存放指针
sync.Pool 存的是接口值（interface{}），而接口内部存储指针时，GC 仍能追踪其指向的对象——但前提是该对象本身没有被其他地方提前释放。问题常出在误以为 “Pool 放进去就安全了”，结果：
立即学习“go语言免费学习笔记（深入）”；
- 放进去的是局部变量地址，该变量作用域已结束（虽然语法上允许，但语义危险）
- 从 Pool 取出后，忘了重置字段或复用逻辑，导致旧指针残留，间接引用已回收对象
- Pool 的
New函数返回新对象，但如果它返回的是栈变量地址（比如&T{}），编译器会自动抬升，没问题；但若返回的是&localSlice[0]这类，就得格外小心底层数组是否稳定
最稳妥的做法：Pool 中只存完整结构体指针（&MyStruct{}），且确保结构体字段不含裸 unsafe.Pointer 或 C 指针。
