Go中import循环本质是编译期符号依赖冲突，需通过接口解耦、显式依赖注入和合理抽象来解决，避免运行时无法绕过的编译错误。
Go 中 import 循环的本质不是“循环引用”，而是“编译期符号依赖冲突”
Go 的 import 不是动态加载，而是在编译期把包内所有导出符号（函数、类型、变量）的声明“拉进来”。一旦 a.go 用到了 b.SomeStruct，而 b.go 又直接用了 a.SomeFunc，编译器在解析 a 包时还没完成 b 包的类型定义，就会报 import cycle not allowed。这不是运行时问题，没法靠延迟初始化绕过，必须从依赖结构上切断。
用接口提前声明契约，让具体实现后置
核心思路：把互相依赖的“具体类型”换成“接口”，而接口定义放在第三方包（或其中一方）中，避免双方都 import 对方的实体类型。
- 比如
user.Service需要调用order.Repository，而order.Repository实现又依赖user.User结构体 —— 这时不要让order包 importuser包，而是定义一个user.UserReader接口（如GetByID(id int) (*User, error)），放在user包里或独立的contract包中 -
order.Repository的方法只接收user.UserReader接口作为参数，不持有user包的任何具体类型 - 最终组装时（如 main 函数），才把
user.NewService()和order.NewRepository()实例传给彼此，此时 import 关系是单向的：main → user、main → order，没有闭环
依赖注入容器不是必需的，但显式传参比全局变量更可控
很多人以为要用 wire 或 dig 才算“依赖注入”，其实 Go 最自然的方式就是构造函数参数传入依赖项。关键在于「谁负责创建、谁负责传递」。
- 避免在
order/repository.go里写import "myapp/user"然后调用user.NewService()—— 这会把创建逻辑和依赖关系锁死在包内 - 改成：
func NewRepository(ur user.UserReader) *Repository，让调用方决定传哪个实现（测试时可传 mock，生产时传真实 service） - 如果依赖层级深（A→B→C→D），不要层层透传，可在顶层（如 cmd/xxx/main.go）一次性 new 所有实例，再按需注入；否则容易演变成“依赖传递污染”
警惕 interface 泛滥和过度抽象带来的维护成本
不是每个类型都要抽接口，也不是每个函数都要接收接口。Go 的哲学是“少即是多”，过早抽象反而增加理解负担。
立即学习“go语言免费学习笔记（深入）”；
- 只有当存在多个实现（如 memoryRepo vs pgRepo）、或需要单元测试 mock 时，才值得为该依赖定义接口
- 不要为单个包内部使用的类型定义接口，比如
user包里User只被自己用，就别搞个Userer接口再到处传 - 接口名应体现行为而非类型，比如用
Notifier而不是UserNotifierInterface；方法少而聚焦，避免DoEverything()这种大接口
真正难的从来不是怎么写 interface，而是判断哪条依赖线必须切、哪条可以容忍紧耦合——这取决于你的迭代节奏和测试覆盖策略。
