Go中不存在“模块循环指针恐慌”错误；import cycle是编译期报错，nil pointer dereference是运行时panic，二者成因、时机、排查路径均不同，且GC能正确处理双向指针引用，内存泄漏主因是未清理的强引用而非循环指针。
Go 里没有“模块循环指针恐慌”这种错误——import cycle 是编译期硬性报错，而 nil pointer dereference 是运行时 panic，两者成因、触发时机、排查路径完全不同。混淆这两个概念，会把问题引向错误方向。
为什么不会出现“循环指针导致的 panic”
Go 的垃圾回收器（GC）能正确处理结构体之间的双向指针引用，只要整个对象图不可达，就会被回收。你看到的内存不降、对象堆积，几乎从来不是因为“循环指针”，而是某处悄悄持有了强引用：
- 全局
sync.Map或map[string]*T里存了没清理的指针 - goroutine 持有闭包捕获的指针，且该 goroutine 因 channel 未关闭或 timer 未 stop 而长期存活
- HTTP handler 函数里直接闭包引用了
*Service，每次请求都新增一个长生命周期引用
这类问题在 pprof 堆分析中表现为 *MyStruct 实例数量持续上涨，但找不到显式 new 或 make 点——根源不在指针是否循环，而在“谁还拿着它”。
真正要防的两种 panic 场景
实际开发中最常踩坑的是下面两类，和“循环”无关，但名字里带“指针”容易误判：
立即学习“go语言免费学习笔记（深入）”；
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
1. 解引用 nil 指针
- 函数接收
*T参数却没判空，直接访问t.Field - 接口变量
i interface{}底层是*T，但i == nil为 false，reflect.ValueOf(i).IsNil()才是真判断 - 结构体字段是
*sync.Mutex这类不可拷贝类型，初始化遗漏导致字段为 nil
2. for range 中取 &v 导致所有指针指向同一地址
- 错误写法：
for _, v := range items { ptrs = append(ptrs, &v) }→ 全部指向最后一次迭代的v - 正确写法一（取原切片地址）：
ptrs[i] = &items[i] - 正确写法二（变量快照）：
for _, v := range items { v := v; ptrs = append(ptrs, &v) }
如何用工具定位真实泄漏点
别靠猜。三步快速收敛：
- 加
runtime.SetFinalizer(obj, func(*T) { log.Println("collected") })—— 如果日志从不打印，说明对象还被某处引用着 - 跑
go tool pprof http://localhost:6060/debug/pprof/heap，看top和web，聚焦inuse_space中重复出现的结构体类型及其调用栈 - 用
go run -gcflags="-m" main.go检查关键函数是否意外逃逸：若输出含moved to heap，说明本该栈分配的变量被推到堆上，可能延长生命周期
最终你会发现，所谓“循环指针恐慌”，其实是“没清理的引用” + “没判空的解引用” + “for range 里的地址复用”这三件事混在一起的结果。分开处理，问题就清晰了。
