Go 不支持循环导入，编译时报错“import cycle not allowed”，需通过接口抽象、依赖倒置、分层设计、回调注入和包结构重构来解耦，核心是明确模块边界与职责。
Go 语言本身不支持循环导入（import cycle），一旦出现 import 层面的双向依赖，编译器会直接报错：import cycle not allowed。这不是运行时问题，而是设计阶段必须解决的架构信号——说明模块边界模糊、职责不清。核心思路不是“绕过”，而是“拆解”：通过接口抽象、依赖倒置、合理分层来打破硬耦合。
用接口隔离实现，让依赖停留在抽象层
循环依赖常发生在 A 模块调用 B 的具体函数，B 又反过来调用 A 的具体函数。解决办法是把其中一方的“被依赖”行为抽象成接口，由调用方定义，被调用方实现。这样 A 只 import B 的接口（可放在独立的 contract 或 port 包），B 实现该接口但无需 import A。
- A 包定义
Notifier接口（如Send(msg string) error） - B 包实现该接口，同时提供一个
RegisterNotifier(n Notifier)方法 - A 在初始化时传入自身满足接口的实例（如
b.RegisterNotifier(a)） - A 不再 import B，B 也不 import A —— 仅共享接口定义（可放在第三包或 A 内）
提取公共抽象层，建立清晰依赖流向
当多个包互相调用核心逻辑时，说明存在隐含的“共享领域模型”或“通用能力”。应主动提取出 domain（领域实体/业务规则）、ports（接口契约）、pkg（工具函数）等稳定层，让其他业务包单向依赖它们，形成 app → domain → pkg 或 handler → service → domain 的向下依赖流。
- 避免
service直接 importhandler或repositoryimportservice - 数据库模型（
model）和 API 请求结构（dto）应分离，转换逻辑放在 service 层 - 使用 Go 的包名语义（如
payment/core、payment/adapter）强化分层意图
延迟绑定与回调注入，替代编译期强引用
某些场景下，A 需在特定时机触发 B 的逻辑（如事件通知、钩子回调），但又不想引入 import 依赖。可用函数类型或回调注册机制实现运行时松耦合。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- A 定义回调类型：
type OnUserCreatedFunc func(*User) error - A 提供
RegisterOnUserCreated(f OnUserCreatedFunc)方法 - B 在初始化时注册自己的处理函数：
a.RegisterOnUserCreated(b.handleUserCreated) - A 内部只持有函数变量，无任何对 B 的 import；B 也只 import A 的公开类型（如
User）
重构包结构，遵循“稳定依赖不稳定”原则
Go 模块的物理结构直接影响依赖健康度。优先按功能域（而非技术层）组织包，同时确保高层策略包（如 usecase、domain）比低层实现包（如 http、postgres）更稳定、更少变更。
- 禁止
http包 importusecase包的实现细节（如具体 struct），只依赖其 interface 或 input/output 类型 - 将跨包共享的类型（如
ID、TimeRange）放入pkg/types等基础包，避免重复定义引发隐式耦合 - 使用
go list -f '{{.Deps}}' ./... | grep 'yourpkg'辅助检查实际依赖路径
基本上就这些。Golang 的循环依赖报错其实是友好的设计守门员——它逼你停下来问：这两个包到底谁该为谁服务？边界在哪？职责是否重叠？真正解耦不靠技巧，而靠对业务本质的清晰建模和对依赖方向的持续审视。
