goland 中 import cycle 报错未显示，通常因构建配置、测试文件、workspace 路径或 gopls 分析路径错位所致；需通过 go build -v、go list、gopls 日志及 go mod graph 等命令精准定位循环链。
GoLand 里看不到 import cycle 报错？先确认是否真被屏蔽了
GoLand 默认不会拦截或隐藏 go build 的 import cycle 错误，但如果你没在 Terminal 或 Build 工具窗口看到 import cycle not allowed，大概率是以下情况之一：
— 项目配置了自定义 build tags 或 go:build 条件，导致某些 _test.go 文件没参与构建，而循环正藏在测试代码里；
— GoLand 的 “Build project automatically” 被关闭，且你只点了「运行」（Run）而非「构建」（Build），而 Run 会跳过部分 import 检查（尤其当 main 包不直接 import 循环链时）；
— 用了 replace 或 go.work，但 GoLand 没加载正确的 workspace 根目录——底部状态栏显示的 module path 和你终端里 pwd 不一致，会导致 gopls 分析路径错位。
用 GoLand 内置 Terminal 快速复现并定位闭环链
别依赖 GUI 构建按钮，直接在 GoLand 的 Terminal 里跑命令，确保环境和 IDE 一致：
— 先执行 go build -v ./...，看完整错误输出。Go 1.21+ 会直接打印类似 package auth imports user, user imports notification, notification imports auth 的完整环路；
— 如果版本旧或输出不全，立刻补查： go list -f '{{.ImportPath}} -> {{join .Imports " -> "}}' ./... | grep -E "(auth|user|notification)"，把疑似包名填进去，快速筛出可疑边；
— 特别注意输出里带 (test) 后缀的行，比如 user (test) -> notification，说明测试文件偷偷拉进了循环，删掉 user_test.go 再试一次，常能立即验证。
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
开启 gopls 日志，让 IDE 告诉你哪几行 import 在打架
GoLand 底层用的是 gopls，它比 go build 更早发现环路，且能标出具体语句：
— 在 Settings → Languages & Frameworks → Go → Go Tools 里，往 Go language server flags 加上 -rpc.trace；
— 重启 gopls（Help → Find Action → “Restart Language Service”）；
— 故意保留一个已知循环，保存文件，然后打开 Help → Show Log in Explorer，搜 import cycle detected —— 日志里会出现类似 import cycle detected: a → b → c → a 的完整路径，甚至附带每个包的 go.mod 位置；
— 关键点：gopls 只标「当前文件中触发环路的那一行 import」，不是整条链。所以如果 a.go 标红了 "b"，得立刻打开 b.go 看它 import 了谁，再顺藤摸瓜。
别信「Structure」面板里的 import 列表
GoLand 的右侧面板「Structure」只展示当前文件显式写的 import，完全不反映间接依赖：
— 它不会显示 init() 函数里调用的跨包函数所隐含的依赖；
— 不会包含 //go:embed 引入的文件所依赖的包；
— 更不会体现 vendor/ 下实际参与构建的包路径（比如 vendor/github.com/x/y 和你代码里的 github.com/x/y 被视为两个不同包，但编译器会报错）；
— 所以看到 Structure 里没循环，不代表没有循环。真正可信的只有 go list -deps 和 go mod graph 的输出。
init() 里调了个函数，那个函数又悄悄 import 了上游包，而这个调用链根本不会出现在任何 import 语句里——gopls 日志和 go build -x 的 importing 行才是唯一能抓到它的线索。
