go指针不阻止gc回收，因gc基于可达性分析而非引用计数；逃逸分析决定堆栈分配，unsafe.pointer转uintptr会绕过gc跟踪，sync.pool中指针需手动确保可达。
Go 的指针不会阻止 GC 回收对象
Go 的垃圾回收器（GC）是基于三色标记-清除算法的并发、非分代、非紧缩式收集器。它不依赖引用计数，也不把“有没有指针指向”作为存活判定的唯一依据——而是从 root set（如全局变量、栈上变量、寄存器中的指针）出发，**可达性分析**才是关键。这意味着：即使你把一个指针保存在 map 或 slice 里，只要该容器本身不可达，整个对象图都会被回收。
常见误解是“只要还有 *T 类型变量，对象就不会被回收”，但实际取决于该指针是否在 root set 中，或能否从 root set 沿指针链访问到。
-
new(T)或&t创建的指针，若其目标对象已脱离作用域且无其他可达路径，下一轮 GC 就可能回收 - 函数返回局部变量地址（如
return &x）是安全的，Go 编译器会自动做逃逸分析，将x分配到堆上——但这不等于“永远不回收”，只是延迟到不再可达时 - 把指针存进全局
map[interface{}]interface{}却忘了删，是典型的内存泄漏场景：map 本身是 root，导致值永远可达
逃逸分析决定指针是否指向堆，而非程序员显式控制
Go 编译器在编译期通过逃逸分析（escape analysis）决定变量分配在栈还是堆。你写 &x 并不必然导致堆分配；如果 x 的地址被返回、传入闭包、或存储在堆数据结构中，它才会“逃逸”到堆。这个过程完全由编译器决策，和 runtime GC 无关，但直接影响 GC 的工作负载。
可通过 go build -gcflags="-m -l" 查看逃逸结果。例如：
立即学习“go语言免费学习笔记（深入）”；
func f() *int {
x := 42
return &x // "moved to heap" —— x 逃逸
}
- 频繁逃逸会增加堆压力，间接提升 GC 频率和 STW 时间（尤其在 Go 1.22 前的旧版本）
- 避免不必要的取地址操作（如
foo(&v)而不是foo(v)），尤其是小类型（int,struct{}） - 注意闭包捕获变量：哪怕只读取一个局部变量地址，也可能导致整个周围变量逃逸
unsafe.Pointer 和 uintptr 容易绕过 GC 可达性跟踪
当使用 unsafe.Pointer 或将其转为 uintptr 后，Go 的 GC 就无法识别该值是一个有效指针。这意味着：即使你用 uintptr 记录了某对象地址，GC 仍可能在下次运行时回收它，而你的 uintptr 变成悬垂指针（dangling pointer）。
这是最危险的 GC 相关误用场景，常见于底层系统编程或自定义内存池。
- 绝不要长期保存
uintptr作为对象引用；必须用unsafe.Pointer保持活跃引用，并确保该Pointer本身在 root set 中（如存在栈/全局变量中） - 若需把指针暂存为整数（如 syscall 场景），务必在使用前转回
unsafe.Pointer，且确保目标对象在此期间持续可达（例如，持有原始指针变量） - Go 1.19+ 对
unsafe使用加了更多检查，但 runtime 仍不扫描uintptr字段——这点极易被忽略
sync.Pool 里的指针对象需要手动管理生命周期
sync.Pool 是 GC 友好的对象复用机制，但它对内部存储的对象不做可达性保证：GC 会清理 pool 中所有未被取用的对象。如果你往 pool 里放的是指针（比如 *bytes.Buffer），要注意这些指针指向的对象本身是否还被其他地方引用。
- pool 中的指针只是“借用”，不代表持有所有权；GC 不关心 pool 里存了什么，只看对象是否可达
- 不要把包含外部指针的结构体（如含
io.Reader字段）盲目放入 pool，除非你确认字段值不会造成意外引用延长 - 利用
sync.Pool.New字段可延迟初始化，但注意：New 创建的对象也受 GC 管理，不是常驻内存
真正难处理的，是那些跨 goroutine 共享指针又缺乏明确所有权语义的场景——GC 不会替你做资源生命周期仲裁，它只负责清理不可达对象。
