Go编译器禁止import循环，因依赖图中存在A→B→A或A→B→C→A等环时会硬性报错；需通过拆分接口与实现、使用函数类型传参、推迟初始化及重划包边界来解决。
为什么 import 循环会导致编译失败
Go 编译器在构建阶段会检查所有 import 语句构成的依赖图，一旦发现 A 包 import B，B 又 import A（直接或间接），就会报错：import cycle not allowed。这不是警告，是硬性拒绝编译——Go 不支持运行时解析或延迟加载来绕过它。
常见诱因包括：把接口和实现塞进同一个包、把模型结构体和数据库操作逻辑混写、测试文件误引了本应被测包的内部辅助函数。
- 循环不一定是两层，可能是 A→B→C→A 这样的环
- 即使用了
_或.导入方式，只要符号被实际引用，仍算作依赖 -
go test时如果xxx_test.go和xxx.go相互引用，也会触发循环（测试文件属于独立包）
拆分接口与实现到不同包是最快见效的方案
把「谁该做什么」的契约（接口）提前定义好，放在一个无依赖的包里（比如 contract 或 domain），让上下游都只依赖这个轻量包，而不是彼此。
例如：用户服务需要发邮件，但邮件发送逻辑在另一个包里。不要让 user 包直接 import mail，而是定义 type Notifier interface { Send(msg string) error } 放在 contract 包中，user 依赖 contract，mail 也实现 contract.Notifier。
立即学习“go语言免费学习笔记（深入）”；
- 接口包不能 import 任何业务包，否则又绕回循环
- 实现包可以 import 接口包 + 基础工具包（如
log、time），但不能 import 其他业务包 - 调用方通过构造函数或 DI 注入具体实现，而非在代码里 new 出来
使用函数类型或闭包传递行为，避免包级依赖
当两个包之间只需要单向传递一小段逻辑（比如回调、校验、转换），不用上升到接口抽象，直接用函数类型更轻量。
比如 payment 包需要调用风控逻辑，但不想 import risk 包。可在 payment.Process() 中增加参数：func(ctx context.Context, orderID string) error，由上层（如 main 或 api 包）注入 risk.CheckOrder 的引用。
- 函数签名必须定义在双方都能访问的地方（通常是调用方所在包或共享的
types包） - 注意闭包捕获的变量生命周期，别意外持有大对象或未关闭资源
- 不适合复杂交互或多方法协作场景，此时还是得用接口
重构时小心 init() 和全局变量引发的隐式依赖
有些循环不是来自 import，而是因为包 A 的 init() 函数里调用了包 B 的函数，而包 B 又在自己的 init() 中反向调用 A —— 这种运行时依赖同样会卡住初始化顺序，导致 panic 或死锁。
全局变量（尤其是带指针或 sync.Once 的）如果跨包初始化，也容易形成隐式绑定。比如 db := NewDB(...) 写在 storage 包的全局变量里，api 包 init 时想用它，就不得不 import storage；而 storage 又依赖 config，config 又读了 api 的环境变量设置……链路就串起来了。
- 尽量推迟初始化，用函数替代全局变量（如
func GetDB() *sql.DB） - 把
init()里的逻辑移到显式初始化函数中，由main统一调度 - 用
go list -f '{{.Deps}}'查看真实依赖树，比肉眼扫 import 更可靠
循环依赖本质是职责边界模糊。解决它最有效的动作往往不是改代码，而是重新划包——问一句：这个结构体/函数/常量，到底属于哪个稳定上下文？不属于的，就挪走。很多人卡在“好像放哪都不太对”，其实是包名没起准，或者领域划分还没收敛。
