go中无传统指针泄漏，但不当持有指针会导致内存无法回收：如sync.map/全局map用*type作key、goroutine闭包捕获大对象指针、defer误捕获指针等，均因根可达性使对象图常驻内存。
Go 语言本身没有传统意义上的“指针泄漏”，但确实存在因不当持有指针导致的内存无法回收——本质是 GC 无法释放本该被释放的对象，常见于闭包捕获、全局映射缓存、goroutine 泄漏等场景。
为什么 sync.Map 或全局 map[*T]V 容易引发隐性内存泄漏
当 map 的 key 是指向堆对象的指针（如 *User），而该指针所指向的结构体又包含大字段（如 []byte、String、嵌套指针），即使原始变量已超出作用域，只要 map 还持有该指针，整个对象图就无法被 GC 回收。
- 避免用指针作 map key；优先用值类型（如
int64、string）或自定义 ID 字段 - 若必须用指针，确保 map 生命周期可控，并在不再需要时显式
delete(m, ptr) -
sync.Map不会自动清理，其LoadOrStore会延长键值生命周期，比普通 map 更隐蔽
goroutine 中闭包捕获指针的典型泄漏模式
闭包若引用了外部函数中分配的大对象指针（如 data := &BigStruct{...}），且 goroutine 执行时间长或永不结束，会导致 data 及其所引用的所有内存一直驻留。
- 检查所有启动 goroutine 的地方，确认闭包是否无意捕获了大对象指针
- 改用显式传参：把需要的数据以值或只读副本（如
data.ID、data.Name）传入，而非传data指针 - 使用
pprof查看runtime.MemStats和/debug/pprof/heap，重点关注inuse_objects是否持续增长
defer 中调用带指针参数的 cleanup 函数的风险
defer func(p *Resource) { p.Close() }(ptr) 这类写法会让 ptr 的生命周期绑定到外层函数栈帧，即使 ptr 在 defer 前已被置为 nil，GC 仍可能因 defer closure 持有原始指针而延迟回收。
立即学习“go语言免费学习笔记（深入）”；
- 改用不捕获指针的 defer：例如
defer ptr.Close()（此时 ptr 是当前值，非闭包捕获） - 若需延迟释放资源且 ptr 可能被提前重置，用
sync.Once或显式标志位控制关闭逻辑 - 注意
defer在 panic 场景下仍会执行，若 cleanup 依赖对象状态，需加 nil 检查：if ptr != nil { ptr.Close() }
真正难排查的不是“指针没释放”，而是“谁还在引用它”——GC 根可达性分析里，一个被 goroutine stack、global var、finalizer 或 runtime 内部结构间接引用的指针，足以让整棵对象树常驻内存。用 go tool pprof -alloc_space 和 runtime.ReadMemStats 对比不同时间点的堆快照，比盯着代码猜更可靠。