指针不触发GC但决定对象存活——只要从根可达，对象就不会被回收；局部变量取地址后因逃逸分析必分配到堆，由GC管理；指针未置nil或未从容器清除则对象持续存活。
Go语言中，指针本身不触发GC，但它是决定对象能否被GC回收的**唯一关键路径**——只要存在一个活跃指针能从根（如栈变量、全局变量）到达某个堆对象，该对象就一定不会被回收。
为什么局部变量取地址后对象就“活”在堆上了
Go编译器通过逃逸分析决定变量分配位置。一旦你对局部变量取地址（&x），并且这个地址可能被函数外使用（比如返回、传入goroutine、存进map），它就必须逃逸到堆上，由GC管理生命周期。
- 常见错误现象：
go build -gcflags="-m" main.go报出... moved to heap，但代码里没看到明显指针赋值——很可能是闭包捕获了变量，或reflect.Value.Addr()、unsafe.Pointer这类隐式逃逸操作 - 小结构体（如
struct{a,b int}）传值比传指针更快；而含string、[]byte、*T字段的结构体，哪怕只有1字节，也必然堆分配（因为底层含指针） - 函数返回局部变量地址，如
func() *int { x := 42; return &x }，x一定逃逸，且生命周期完全脱离函数作用域
指针没清空，GC就永远“看不见”它
GC只看可达性，不看语义。一个指针变量即使逻辑上已废弃，只要它的值还没被设为nil，或没从容器中真正删除，它指向的对象就仍算“可达”。
- 切片/映射中保存
*T，执行delete(m, key)或s = s[:0]后，若未显式置m[key] = nil或s[i] = nil，原对象仍被强引用 - 全局
sync.Map或长期运行的goroutine持有*bytes.Buffer，缓冲区内容会持续驻留，甚至拖慢标记阶段（GC需遍历每个指针字段） -
fmt.Errorf("err: %v", &largeStruct)会让largeStruct因接口隐式持针而长期存活——应改用fmt.Errorf("err: %+v", largeStruct)（值拷贝）
怎么验证和优化指针带来的GC压力
不能靠猜，得用工具定位真实逃逸点和堆分配热点。
