go禁止import循环因编译期构建依赖图时发现闭环（如A→B→A）即报错；解决方式包括：抽离共享类型至独立types包、用接口解耦依赖方向、警惕嵌入/init/全局变量引发的隐式循环。
为什么 Go 的 import 会报 “import cycle not allowed”
Go 编译器在解析 import 语句时，会构建一个有向依赖图；一旦发现 A → B → A 这类闭环，立刻终止编译并报错 import cycle not allowed。这和 java 或 python 不同——Go 不允许运行时动态加载或接口延迟绑定来绕过编译期检查，所以循环依赖是硬性禁止，不是警告。
常见诱因包括：把共用类型（如 User、Error）和业务逻辑混在一个包里；两个服务层包互相调用对方的 handler 或 service；或者把数据库模型和 http 路由定义放在同一包又被其他包双向引用。
把共享类型抽到独立的 types 或 model 包
这是最常用也最有效的破环方式。核心原则：只让依赖流向“更稳定、更抽象”的包，避免业务逻辑包之间直接引用。
- 把结构体、常量、基础错误类型等定义移到新包，例如
github.com/your/app/types - 原
user包和order包都只import "github.com/your/app/types"，不再互相 import - 确保该包不 import 任何业务包（即它不能有
import "github.com/your/app/user"） - 如果需要序列化相关方法（如
jsONMarshal），优先用内嵌字段或组合，而非在types包里写具体业务逻辑
package types type User struct { ID int64 `json:"id"` Name string `json:"name"` } type Order struct { ID int64 `json:"id"` UserID int64 `json:"user_id"` }用接口解耦，把依赖方向反转为“依赖抽象”
当两个包必须交互（比如 payment 需要通知 notification），但又不能直接 import 对方时，把调用方需要的契约提前定义在被调用方的包里，或更推荐——定义在第三方接口包中。
立即学习“go语言免费学习笔记（深入）”；
- 在
notification包里定义Notifier接口，并导出 - 让
payment只依赖这个接口，不 importnotification包实现 - 实际初始化时，由
main或cmd层注入具体实现（如¬ification.EmailNotifier{}） - 接口定义尽量窄：只包含
payment真正需要的方法，避免暴露无关行为
package notification type Notifier interface { Send(msg string) error }然后在 payment/service.go 中：
type PaymentService struct { notifier Notifier // 注意：这里只是接口类型，不 import notification 包 } func NewPaymentService(n Notifier) *PaymentService { return &PaymentService{notifier: n} }警惕隐式循环：嵌入、init 函数、全局变量初始化
有些循环不体现在 import 行，但依然触发编译失败。典型场景：
-
user/model.go嵌入了order.Item，而order/model.go又嵌入了user.Profile - 某个包的
init()函数里调用了另一个包的函数，而后者又在自己的init()中反向调用 - 全局变量使用了跨包类型，例如
var DefaultClient = &http.Client{Timeout: user.DefaultTimeout}，而user.DefaultTimeout又来自另一个包
这类问题往往在添加新字段或重构 init 逻辑后突然暴露。排查时可用 go list -f '{{.Deps}}' ./pkg/a 查看依赖链，或用 go mod graph | grep 辅助定位闭环路径。
真正难处理的是跨模块边界（如 internal/ 和 cmd/ 之间）的间接引用——它们容易被忽略，直到 CI 报错才发觉。