exportloopref 专查 for 循环中错误导出局部变量地址引发的并发风险，非 import cycle 检测工具；真正检测导入循环需依赖 go build 报错、go mod graph 分析或 gopls 实时提示。
用 exportloopref 扫描循环变量导出风险，不是 import cycle 检测工具
exportloopref 不检测包级 import 循环，它只检查函数内 for 循环中错误地导出局部变量地址（比如 &v），导致多个指针指向同一内存地址。这是并发和数据一致性问题，和 import cycle not allowed 完全无关。误把它当依赖环检测工具，会漏掉真正的编译失败原因。
真正能自动发现 import cycle 的只有 go build + go mod graph 组合
Go 编译器本身不提供可调用的 API 检测循环导入，所有“自动检查”都基于构建流程触发：
-
go build是唯一权威判定者：只要报import cycle not allowed，就说明存在环；不报，就暂时安全 -
go mod graph输出模块级依赖边，适合快速筛出可疑回边：go mod graph | grep 'your-module/' | grep -E 'pkgA.*pkgB|pkgB.*pkgA' -
go list -f '{{.ImportPath}} -> {{join .Imports " -> "}}' ./生成包级导入链，配合grep和手动追踪更准，但需注意_test.go文件也参与构建图 - 如果用了
replace或vendor，必须加-mod=readonly或先执行go mod vendor，否则go list查的是 proxy 路径而非真实路径
gopls 是最接近“编写时自动检查”的方案
VS Code + Go 插件启用 gopls 后，保存文件时会实时分析整个 workspace 的 import 图，并把直接导致环的那行 import 标红——不是等 go build 报错才提醒。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 它只标出“当前文件中造成环的 import”，不是整条环路；你需要点开被标红的包，再看它的
import是否也被标红 - 若项目含多个 module 或
go.work，确认 VS Code 状态栏显示的是你预期的 workspace 根目录，否则gopls加载不全 - 开启 RPC 日志：
"go.languageServerFlags": ["-rpc.trace"]，日志里会出现类似import cycle detected: a → b → c → a的完整路径
自研工具只能做辅助，不能替代编译器判断
如果你真想写个脚本提前预警，可行做法是封装 go list + 图遍历逻辑，但要注意几个硬伤：
立即学习“go语言免费学习笔记（深入）”；
- 无法覆盖测试文件隐式引入的环 ——
_test.go默认参与构建，但常被忽略 - 对
//go:embed或//go:generate生成的代码无感知，而它们可能悄悄引入反向 import - 无法识别 interface 类型定义带来的间接依赖：只要
type X interface{...}定义在包 B，包 A 声明func F(x B.X)，就算没显式import B，编译器仍视为依赖 - 所有自研逻辑都跑在
go build之后，本质是事后分析，不是前置拦截
真正容易被忽略的，是那些没写 import 却构成依赖的场景：函数参数类型、返回值类型、嵌入结构体字段类型，只要来自另一个包，就计入依赖图 —— 这些连 go list 都不会显示，只能靠人眼审接口签名。
