go变量生命周期由根对象可达性决定而非作用域；即使函数内声明，若地址逃逸至堆并被长期对象持有，将存活至其被释放。
变量生存周期不由作用域决定，而由是否被根对象可达决定
Go 的变量生命周期不是“出了 {} 就立刻销毁”，而是看它是否还能被 GC 根（如全局变量、栈上活跃指针、寄存器值）间接访问到。哪怕变量声明在函数内，只要它的地址被逃逸到堆上并被某个长期存活对象持有，它就会活过函数返回。
- 常见错误现象：
runtime.GC()后发现本该“结束”的变量还在内存里 —— 实际是它被闭包、全局 map 或 goroutine 持有，没真正断开引用 - 使用场景：写异步任务时，把局部
buf的地址传给go func()，结果buf被提升到堆，生命周期延长至 goroutine 结束 - 判断方法：用
go build -gcflags="-m -l"看逃逸分析，出现... escapes to heap就说明变量生命周期已脱离栈帧控制
指针引用导致变量无法被及时回收的典型模式
Go 的 GC 是基于三色标记的并发清除，不依赖引用计数。但只要有一个活着的指针指向某块内存，这块内存就不会被回收 —— 即使这个指针藏得很深，比如嵌套在结构体字段、切片元素、map value 里。
- 常见错误现象：
map[string]*User中存了大量*User，但忘了清理不用的 key，导致 User 对象永远不可达却无法释放 - 参数差异：传
*T和传T在逃逸行为上可能完全不同；即使函数只读*T字段，编译器仍可能因无法证明“不会存储该指针”而强制逃逸 - 性能影响：大量短生命周期对象被指针意外持有，会抬高堆占用，触发更频繁的 GC，表现为
GC pause时间波动增大
如何验证某个变量是否真被 GC 回收了
不能靠打印或延迟等待来“观察”，得用运行时指标和可控触发点交叉验证。
- 使用场景：调试内存泄漏时，想确认某类结构体是否真的被释放
- 实操建议：
var m runtime.MemStats runtime.ReadMemStats(&m) fmt.Println("Alloc =", m.Alloc)在关键节点前后调用，配合runtime.GC()强制触发一次回收（仅用于调试） - 容易踩的坑：
runtime.GC()不保证立即回收所有可回收对象；且如果对象被 finalizer 关联，还会延迟到 finalizer 执行完才真正释放 - 注意：
debug.SetGCPercent(-1)可临时禁用自动 GC，便于观察 Alloc 增长趋势，但上线必须关掉
避免意外延长生命周期的三个硬约束
不是靠“小心点”就能避开的问题，得从编码习惯和工具链入手。
立即学习“go语言免费学习笔记（深入）”；
- 不要把局部变量地址存进全局
sync.Pool或map，除非你明确管理其生命周期；sync.Pool.Put()不等于“释放”，只是归还，下次Get()还可能拿到它 - 关闭 channel 后，别再往里面发数据，否则接收 goroutine 持有的指针可能持续引用已废弃的结构体
- 用
pprof的heapprofile 查泄漏时，重点看inuse_space中 topN 类型的 source line —— 往往就是那个“以为早就结束了”的变量分配点
