go指针不影响gc可达性判断，gc只关注从根对象是否可达；逃逸分析决定栈/堆分配，闭包和全局存储会延长对象生命周期，unsafe.pointer需配合普通指针防误回收。
Go 的指针不会让对象“逃过” GC
Go 的垃圾回收器基于可达性分析，只关心变量是否能从根对象（如全局变量、栈上的局部变量）通过指针链访问到。只要一个对象没有任何活跃的指针指向它，哪怕它内部有大量 *T 字段，也不会影响其被回收的时机。
常见错误现象：runtime.GC() 后发现对象没被立即回收，就怀疑是某个 *int 没释放；其实更可能是该对象仍被栈上某个未出作用域的变量间接引用着。
- 栈上变量生命周期由编译器决定，不是靠“手动 nil 指针”来触发释放
-
new(T)或&T{}分配的对象，只要没有根可达路径，GC 就会清理——和有没有指针字段无关 - 闭包捕获变量时，可能隐式延长指针所指对象的生命周期（比如闭包里用了
&x，而 x 是局部变量）
哪些指针会让对象变“不可达”？
真正影响可达性的，是“从根出发能否抵达”的指针路径，不是指针本身的存在。Go 编译器会做逃逸分析，决定变量分配在栈还是堆，这直接影响 GC 是否需要管理它。
使用场景：写高性能服务时，常想避免堆分配。但若函数返回了局部变量的地址（如 return &x），x 就必须逃逸到堆，进入 GC 管理范围。
立即学习“go语言免费学习笔记（深入）”；
- 返回局部变量地址 → 必然逃逸 → 进入 GC 可达图
- 把指针存进全局 map / channel / slice → 该对象变成根可达，不会被回收
- goroutine 中启动的匿名函数若引用了外部指针变量，且 goroutine 仍在运行，对象就保持可达
unsafe.Pointer 和 uintptr 容易绕过 GC 可达性检查
这是最危险的边界情况。unsafe.Pointer 本身不参与可达性追踪；如果用它把对象地址转成 uintptr，再丢掉原始指针，GC 就会认为该对象不可达，可能提前回收——哪怕你后续还打算用那个 uintptr。
错误示例：p := &x; u := uintptr(unsafe.Pointer(p)); // 此刻 p 已无引用，x 可能被 GC
-
unsafe.Pointer能被 GC 追踪，但uintptr不能——它是纯数值 - 必须保证至少有一个普通指针（
*T）持续指向对象，才能防止 GC 回收 - 标准库中
sync.Pool内部就小心维护了这种指针引用，避免对象被误回收
调试 GC 可达性问题的实用方法
别猜，用工具看实际的可达路径。Go 提供了运行时接口和调试手段，比读源码更快定位“为什么这个对象还没被回收”。
关键命令：go tool trace 和 GODEBUG=gctrace=1 是基础，但要查具体对象，得用 runtime.ReadMemStats 配合 pprof 的 heap profile。
- 开启
GODEBUG=gctrace=1可看到每次 GC 扫描了多少对象，但看不出谁引用了谁 -
pprof -http=:8080 http://localhost:6060/debug/pprof/heap查看存活对象及调用栈 - 用
runtime.SetFinalizer做探测：给对象设 finalizer，若没被调用，说明它还在可达图里
复杂点在于：可达性不是静态的，它随 goroutine 栈帧变化、map 删除、channel 关闭等动态事件实时更新。一个变量在第 5 行还被引用，第 12 行可能就彻底断连了——但栈帧没销毁前，编译器未必优化掉那个指针槽位。
