Go 的 GC 能正确处理循环引用，内存不释放主因是意外强引用；需检查全局 map、未取 channel、goroutine 闭包捕获等，并用 pprof 和 SetFinalizer 辅助定位。
循环引用在 Go 里其实不会直接导致内存泄露
Go 的垃圾回收器（GC）能正确处理结构体之间的循环引用，只要这些对象整体不可达，就会被回收。你看到的“内存不释放”，大概率不是 GC 失效，而是对象被意外持有了强引用——比如注册到全局 map、放进 channel 没取、或被 goroutine 长期闭包捕获。
常见错误现象：runtime.ReadMemStats 显示 HeapInuse 持续上涨，pprof 堆分析发现大量结构体实例堆积，但找不到明显泄漏点。
- 检查是否把结构体指针存进了全局
sync.Map或map[interface{}]*MyStruct却忘了清理 - 确认 goroutine 是否因未关闭的
chan或time.Ticker一直存活，并间接持有结构体 - 避免在回调函数中直接捕获结构体指针（如
http.HandleFunc里闭包引用s *Service），改用传参或弱引用模式
结构体字段设计时如何主动切断引用链
即使 GC 能处理循环，人为制造强引用链仍会延长对象生命周期，增加 GC 压力，尤其在高频创建/销毁场景下（如 HTTP 中间件、事件处理器）。关键是在设计阶段就明确所有权和生命周期边界。
使用场景：两个结构体需要互相调用方法，但生命周期不同（如 *DB 长期存在，*RequestCtx 短暂存在）。
立即学习“go语言免费学习笔记（深入）”；
- 用接口替代具体类型字段：
type RequestCtx struct { db DBer }，而非db *DB，避免隐式强引用 - 对非拥有关系的引用，改用
uintptr或unsafe.Pointer（慎用，仅限高性能底层模块） - 更安全的做法是注入函数而非结构体：
onDone func() error，而不是owner *Service - 如果必须存指针，约定“反向引用不参与 GC 根扫描”：例如在
*Node中存parent unsafe.Pointer，并在Finalizer中清空（不推荐，仅作兜底）
用 pprof 和 runtime.SetFinalizer 快速验证是否真有循环泄漏
SetFinalizer 不是内存泄漏检测工具，但它能帮你确认对象是否被 GC —— 如果 finalizer 从不执行，说明对象还被某处引用着；如果执行了但内存没降，问题在别处（如 Cgo 内存、未释放的 fd）。
实操建议：
- 给可疑结构体加 finalizer：
runtime.SetFinalizer(obj, func(*MyStruct) { log.Println("collected") }) - 配合
pprof.WriteHeapProfile抓堆快照，用go tool pprof查看top和web，聚焦inuse_space中重复出现的结构体类型 - 注意：finalizer 不保证何时运行，也不保证一定运行；仅用于调试，不能用于资源清理逻辑
- 若怀疑是 runtime 层面问题，用
GODEBUG=gctrace=1观察 GC 日志中scvg和sweep行为
嵌入结构体时最容易忽略的隐式引用陷阱
Go 的结构体嵌入（embedding）看起来像“组合”，但编译器会把嵌入字段的地址直接铺开到外层结构体中。一旦外层结构体被长期持有，所有嵌入字段也会被一并钉住 —— 包括你本以为只是临时使用的 sync.Mutex 或 bytes.Buffer。
典型问题：
- 在 request-scoped 结构体中嵌入
log.Logger（它内部持有一个*sync.Pool和输出 writer），结果整个 logger 实例无法释放 - 嵌入
context.Context字段（如ctx context.Context），而该 ctx 来自context.Background()或带 cancel 的父 ctx，导致 ctx 树无法剪枝 - 解决方案：用字段代替嵌入；或只嵌入接口（如
io.Writer），避免带状态的结构体被拖住 - 检查
go vet -shadow和staticcheck，它们能发现部分隐式引用延长生命周期的问题
真正难的不是写出让 GC 无法处理的代码，而是让人类自己理清楚谁该拥有谁、谁该先销毁。很多“泄漏”其实是生命周期契约没说清，而不是技术限制。
