go禁止循环导入，需通过合并高耦合类型至同一包、用接口抽象解耦、提取共享类型到无依赖包、依赖注入替代硬编码导入来解决。
Go语言不支持包级循环导入，一旦出现就会编译失败，报 import cycle not allowed。这不是临时障碍，而是架构设计发出的明确信号：模块边界模糊、职责纠缠、抽象不足。解决它不能靠绕过或掩盖，而要从结构入手做实质性调整。
优先合并高耦合实体到同一包
当两个类型天然双向引用（如 User ↔ Group、Person ↔ Team、Order ↔ User），且生命周期和业务语义紧密绑定时，强行拆成独立包只会制造循环。Go 的惯用做法是统一归入一个内聚包（如 models、domain 或 entities），再按功能分文件组织：
-
models/user.go定义User结构体，字段可直接引用同包的Group -
models/group.go定义Group，字段可直接包含[]User - 所有方法、关联逻辑、验证规则都围绕这个领域边界展开，不引入外部业务包
用接口抽象打破编译期依赖
若模块间需协作但又不属于同一领域（如 service 层调用 repository，或 handler 调用 notifier），应通过接口解耦。关键在接口的位置和定义方式：
- 接口必须定义在**双方都可导入、但又不依赖任一方**的包中，例如
contract、port或domain - 接口方法参数/返回值尽量用基础类型、
context.Context或该接口包自定义的轻量 DTO（如type CreateUserReq struct{ Name string }） - 避免在接口中暴露具体 struct 或写操作方法（如
Save()），否则会把实现细节泄漏进契约
提取公共内容到无依赖的共享包
多个包共用的数据结构、错误变量、常量等，不应复制，也不应放在任一业务包里——那会引发反向依赖。正确做法是新建一个极简包（如 model、types 或 shared）：
- 只放
struct、const、var ErrXXX error，不写任何方法 - 不 import 任何业务包，运行
go list -f '{{.Imports}}' ./model输出应为空或仅含标准库 - 所有业务包都 import 它，但彼此不互相 import，依赖树变成单向发散
用依赖注入替代硬编码导入
运行时行为比编译期引用更灵活。当某模块需要另一模块的能力，不要在代码顶部 import，而是通过构造函数或方法参数传入：
func NewOrderService(u UserProvider) *OrderService-
func (h *Handler) ServeHTTP(w, r) { h.notifier.Send(...) }，其中notifier是初始化时注入的接口实例 - 避免在包层级使用全局变量或 init 函数来“自动连接”，那会让依赖关系隐式且难以测试
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
