Go指针不直接控制对象生命周期，但通过影响可达性间接决定GC回收时机：只要存在有效指针引用，对象即存活；置nil、从集合删除指针或避免无意共享可助及时回收；显式管理应依赖context、Close方法或sync.Pool。
Go指针本身不能直接“控制”对象生命周期，但它深刻影响生命周期——通过是否被引用、是否逃逸、是否被长期持有，间接决定GC何时回收对象。
指针与对象存活强相关
Go的垃圾回收器只回收不可达对象。只要存在一个有效指针（包括栈上变量、全局变量、接口值、map/slice元素等）指向某块内存，该对象就视为“可达”，不会被回收。
- 局部变量取地址后返回：
func() *int { x := 42; return &x }→x逃逸到堆，生命周期延长至指针不再被引用为止 - 指针存入全局map或缓存：即使原始作用域已结束，只要map还持有该指针，对象就无法释放
- 指针赋给
interface{}或error：会隐式保留底层对象引用，常见于fmt.Errorf("...", &largeStruct)导致大对象滞留
指针不是开关，但能“锁住”生命周期
你无法用指针主动启动或终止一个对象的生命周期，但你可以通过操作指针来干预它的可达性：
- 显式置
nil：如ptr = nil，若这是最后一个引用，可助GC及时回收 - 从集合中删除指针：从map、slice中移除指向对象的指针，是释放的关键一步
- 避免无意共享：多个goroutine共用同一指针时，不仅引发竞态，还可能因任意一方长期持有而拖慢回收
真正可控的生命周期机制在别处
想主动管理生命周期，应依赖Go提供的显式机制，而非依赖指针本身：
- context.Context：传递取消信号，配合指针所指对象的清理逻辑（如关闭连接、停止协程）
- Close()/Free()方法：尤其对含C内存或系统资源的对象，必须显式释放，指针只是访问入口
- sync.Pool：复用临时对象，缩短分配-回收周期，减少GC压力
基本上就这些。指针是内存访问的路径，不是生命周期的开关；理解“谁还指着它”，比纠结“怎么让指针活久一点”更重要。
