go编译器的import cycle检查发生在编译期解析阶段，只依赖import声明构建有向图，与init()、单例、条件分支或函数体内容无关；真正破环需抽离共享类型、接口下沉或依赖注入，使依赖图为dag。
Go 编译器不认单例模式，init() 函数也不能绕过循环导入检查——只要 import 语句存在，无论是否用到、是否在 if false 分支里，都会参与依赖图构建。所谓“用单例或 init() 规避循环导入”，本质是误解。
为什么 init() 和单例都不能解决 import cycle
Go 的 import cycle 检查发生在编译期解析阶段，早于任何代码执行（包括 init()）。它只看 import 声明构成的有向边，和函数体内容完全无关。
-
init()是包初始化的一部分，但前提是包能被成功加载；而循环导致包根本无法进入初始化流程 - 所谓“单例”通常指全局变量 +
sync.Once，但它依赖的类型定义如果来自另一个包，那个包仍需被 import —— 一旦形成 A → B → A，报错立刻发生 - 哪怕你把所有逻辑塞进
main()里，只要两个包互相import，错误照旧
常见误用场景：延迟赋值 ≠ 解除依赖
有人尝试这样写：
// user/service.go
var UserService *Service
func InitUserService(s *Service) {
UserService = s
}
然后在 notification/handler.go 里调用 user.InitUserService(...)。这看似“解耦”，但只要 notification 包还 import "yourapp/user"，而 user 又 import "yourapp/notification"，循环就已成立。
- 函数签名里的参数类型、返回值类型，只要来自对方包，就构成 import 依赖
- 哪怕只 import 一个空接口（如
type Notifier interface{}），只要定义在 notification 包里，user 包 import 它就仍算依赖 - 真正要打破循环，不是推迟调用，而是让双方都不直接 import 对方
真正有效的破环路径只有三条
所有可行解法都指向一个目标：让依赖图变成有向无环图（DAG）。
-
抽离共享类型：把共用的
User、ErrNotFound、Event等定义移到独立包（如pkg/types），该包不能 import 任何业务包；user 和 notification 都只 importpkg/types -
接口下沉：把回调契约（如
Notifier）定义在第三方包（如pkg/contract或internal/port），user 和 notification 都 import 它，但彼此不 import -
依赖注入由上层组装：在
main或cmd包里 new 实例并传入，比如notification.New(&user.Service{})，此时 user 和 notification 仍是单向依赖（都依赖 main，互不依赖）
最容易被忽略的一点：测试文件（*_test.go）经常偷偷引入循环。比如 user/user_test.go import 了 testutil，而 testutil 又 import 了 notification —— 这条链不会出现在主代码流里，却足以触发 import cycle。排查时务必把 _test.go 纳入依赖图。
