Go中指针不触发GC但决定对象是否可回收，因GC依赖可达性分析；指针越多、嵌套越深、结构越复杂，标记耗时越长；未置nil、缓存不清理、闭包捕获等导致隐式强引用，延长对象生命周期。
Go 中的指针本身不触发 GC，也不绕过 GC，但它直接决定 GC 能不能回收一个对象——只要还有指针能“摸到”它，GC 就必须留着。
为什么指针会拖慢 GC？
GC 的核心是可达性分析：从根对象（全局变量、栈上变量、寄存器）出发，顺着所有指针链递归标记。每多一条活跃指针，就多一条扫描路径；指针越多、嵌套越深、结构越复杂，标记阶段耗时就越长。
- 大量
*bigStruct存进
map[string]*bigStruct，GC 必须遍历整个 map 并检查每个指针目标是否存活 -
goroutine 长期持有
*bytes.Buffer并阻塞在ch ，该 buffer 一直不可回收，堆持续增长 - 闭包捕获了
&hugeData，而闭包被注册为 HTTP handler，导致hugeData在整个服务生命周期内驻留
怎么判断指针是不是在偷偷逃逸？
逃逸是堆分配的起点，也是 GC 压力的第一道入口。编译器根据指针使用方式决定变量放栈还是堆——你写的 &x 很可能让 x 立刻上堆。
- 用
go build -gcflags="-m -m"查看逃逸日志，重点关注... escapes to heap - 常见逃逸场景：
return &x、go f(&x)、m["k"] = &x、interface{}(&x) - 小结构体（如
struct{a, b int}，通常 ≤16 字节）值传递比传指针更快，也更少逃逸
指针没置 nil，对象就一直活？
是的。Go 没有悬空指针，但有“隐式强引用”——只要指针还存在且没被显式切断，它指向的对象就永远可达。
-
cache := sync.Map{}; cache.Store("key", &largeObj)→ 不调用Delete，largeObj永远不回收 - 结构体字段是
*[]byte，用完后没设成nil，GC 无法识别该字段已失效 -
fmt.Errorf("failed: %v", &hugeStruct)→error接口隐式持有了指针，大对象被意外延长生命周期
如何让指针配合 GC 工作得更轻快？
不是少用指针，而是控制指针的“影响力范围”：谁持有它、持有多久、有没有出口。
- 大对象传参优先用
*T，但返回后尽快让接收方明确释放语义（比如调用Close()或清空字段） - 全局缓存中存指针时，搭配
sync.Pool或带 TTL 的清理逻辑，别只存不删 - 对 C 内存（
*C.struct_x）完全不走 GC，必须配Free()+runtime.SetFinalizer双保险 - 用
pprof抓go tool pprof，重点看alloc_objects和inuse_space，定位哪些指针链撑起了最大内存块
真正卡住 GC 的，往往不是某一行 &x，而是那个忘了从 map 删除的 key、那个始终没 close 的 client、那个被 error 接口悄悄锁住的大 struct —— 指针只是门把手，开门关门，还得人来动手。
