Go 中循环引用不会导致内存泄漏，真正原因是本该不可达的对象被 GC 根意外持有；用 *T 作 map key、goroutine 闭包捕获指针、defer 闭包传指针等均易引发泄漏，需用值类型 key、显式传值、直接 defer 调用并辅以 pprof 验证。
Go 语言中，循环引用本身不会导致内存泄漏——GC 能正确回收不可达的循环对象。真正的问题不是“有循环”，而是“本该不可达的对象，因为被某个 GC 根意外持有而持续可达”。
sync.Map 或普通 map 用 *T 当 key 是高危操作
当 map 的 key 是 *User 这类指针，且 User 包含大字段（如 []byte、map[string]interface{}），哪怕原始变量早已离开作用域，只要 map 还存着这个指针，整个对象图就仍被根（全局变量）间接引用，无法回收。
- 改用值类型作 key：比如
UserID int64、string（如 UUID）或自定义type UserKey struct{ ID int64 } - 若必须用指针（极少数场景），确保 map 生命周期可控，并在业务逻辑明确结束时调用
delete(m, ptr) -
sync.Map尤其危险：它的LoadOrStore不仅不清理旧值，还会延长键值对生命周期；比普通 map 更难察觉泄漏
goroutine 闭包捕获指针时别拖住整棵树
常见写法 go func() { process(data) }() 中，如果 data 是 &BigStruct{...}，而 goroutine 执行时间长或永不退出，那 data 及其所引用的所有子对象（比如 data.Payload 是几 MB 的 []byte）都会一直驻留。
- 显式传值：如果结构体不大，直接传
data（而非&data）；或只传必要字段：go func(payload []byte) { ... }(data.Payload) - 避免在循环里直接捕获迭代变量：
for _, u := range users { go func() { log(u.Name) }() }会导致所有 goroutine 共享最后一个u地址；应改为go func(u User) { ... }(u) - 用
pprof验证：运行go tool pprof http://localhost:6060/debug/pprof/heap，看inuse_objects是否随请求稳定，还是持续上涨
defer 闭包里传指针容易延长对象生命周期
defer func(p *Resource) { p.Close() }(ptr) 这种写法会让 ptr 的原始地址被闭包捕获，即使你在 defer 前写了 ptr = nil，GC 仍可能因闭包持有该指针而延迟回收。
立即学习“go语言免费学习笔记（深入）”；
- 优先用直接调用：
defer ptr.Close()（此时传的是当前值，不是闭包捕获的引用） - 如果必须用闭包（比如要加日志或错误处理），确保做 nil 检查：
defer func(p *Resource) { if p != nil { p.Close() } }(ptr) - 对关键资源（如 DB 连接、HTTP 响应体），更推荐在业务逻辑结束处显式关闭，而不是依赖 defer 绑定到函数栈帧
最难定位的从来不是“哪里用了指针”，而是“谁还在引用它”。一个被 runtime 内部结构、未 stop 的 time.Ticker、或未释放的 http.Transport 持有的指针，足以让整棵对象树常驻内存。别只盯着代码猜，用 go tool pprof -alloc_space 对比不同时间点的堆快照，才是实锤依据。
