Go编译器在解析import图时发现闭环会直接报错终止编译，因检查发生在编译前期，只依赖包级import声明是否构成有向环，与函数调用、变量使用、init执行无关。
Go 编译器在解析 import 图时发现闭环，会直接报 import cycle not allowed 并终止编译——这不是运行时问题，也不是顺序或时机问题，没法“绕过去”，必须重构依赖结构。
为什么改 import 顺序或挪文件没用
Go 的 import cycle 检查发生在编译前期，只看包级 import 声明是否构成有向环，和函数是否调用、变量是否使用、init 是否执行完全无关。哪怕只是 a.go 里有一行 import "pkgB"，而 pkgB 里也有一行 import "pkgA"，立刻报错。
常见误操作包括：
- 把一个函数从
pkgA挪到新文件，以为“物理隔离”就能打破循环，结果 import 语句还在，照样报错 - 删掉某个
import后编译通过，但功能逻辑断了——说明你只是掩盖了问题，没解决根本耦合 - 在
init()里跨包调用，以为“不显式 import 就没事”，但只要包 A 的 init 调用了包 B 的函数，而包 B 又 import 了包 A，就已构成隐式循环（编译器仍能静态分析出来）
怎么快速定位循环路径
Go 1.21+ 版本会明确输出完整闭环链，比如：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
import cycle not allowed: package auth imports package user, package user imports package notification, package notification imports package auth
如果你用的是旧版 Go（
- 临时注释掉一个包的
import，看另一个包是否还能编译；能编译，说明它依赖的那个包就是闭环节点 - 用
go list -f '{{.Deps}}' pkgA查看包 A 直接依赖哪些包，再对每个依赖重复执行，画出依赖图 - 重点关注测试文件（
*_test.go）：它 import 被测包的同时，又 import 了 mock 工具包，而该工具包反过来 import 了业务类型，极易触发 cycle
最常用的三种解法及适用场景
核心思路不是“删 import”，而是让依赖变单向、变抽象、变延迟。
-
抽离共享类型到独立包：当两个包互相 import 是因为共用
struct、error或常量时，新建domain/或types/包，把它们移进去，然后让双方都只 import 这个新包。注意：这个包不能 import 任何 infra 或 handler 层代码，否则又绕回循环 -
用 interface + 依赖注入反转依赖方向：典型场景是 service 需要调用 repo，而 repo 又要回调 service 更新状态。此时在
contract/包中定义type StatusUpdater interface { Update(id int) error }，service 实现它，repo 接收该接口作为构造参数，不再 import service 包 -
合并强耦合逻辑到同一包：如果 A 和 B 的代码粒度太细、交互太密（比如一个 handler 和它专属的 validator），且没有被其他包复用，直接合并为
internal/auth或app/user更干净。别为了“分包”而分包，树状依赖的前提是每个包职责清晰
容易被忽略的细节
很多循环不是写出来的，是“导出来”的。比如：
- 把本该私有的 DTO 结构体放在
model.User并导出，结果http/和db/都 import 它，形成 A → model → B → model 的隐式环 - 在
errors.New("xxx")上加包级变量，然后跨包反复 import 这个变量——类型相同但包不同，照样算依赖 - 用
type MyErr = errors.Err做别名，看似轻量，但只要原包被 import，依赖就存在 -
internal/目录不是银弹，但它能帮你暴露问题：如果某工具函数只能被同级包 import，却总被跨层调用，说明它本该属于 domain 层，而不是塞在 infra 里
真正难的不是写代码，是判断哪部分该抽象、哪部分该合并、哪部分该彻底移出公共视野——这需要你盯着 import 图，问自己一句：这个包，到底该知道谁？
