go编译器遇import循环直接报错，需用go list逐层展开依赖定位闭环；接口应定义在独立contract/domain包中，避免反向依赖；共享结构体须置于无方法的model包；业务边界模糊才是循环主因。
Go 编译器在解析 import 时发现闭环依赖，会直接报 import cycle not allowed，没有绕过办法——不是警告，不看函数是否调用，也不接受延迟加载或空导入。必须重构。
怎么快速定位循环依赖链
肉眼扫 import 语句容易漏掉间接依赖（比如 A → B → C → A）。go list 是最可靠的第一手工具：
- 运行
go list -f '{{.Deps}}' ./pkg/a查看pkg/a直接依赖的包列表 - 对每个依赖包再执行一次，逐层展开，直到出现重复包名——那就是闭环节点
- 如果输出里有类似
github.com/x/y imports github.com/x/z imports github.com/x/y，就说明路径已闭环 - 注意：测试文件（
*_test.go）也可能参与循环，别忽略pkg/a_test的 import
用 interface 解耦时，接口该放哪、怎么定义
接口位置错，反而会引入新循环。常见错误是把 UserRepo 接口放在 user 包里，结果 repo 包实现它时不得不 import user，而 user 又要 import repo。
- 接口应定义在**双方都可 import 但又不依赖任一方**的包里，例如
contract或domain - 接口方法参数/返回值尽量用基础类型（
int,string,error）、context.Context，或该接口包自己定义的轻量 DTO（如type CreateUserReq struct{ Name string }） - 避免在接口里塞
Save()、Delete()这类写操作方法——这通常意味着职责越界，该转为 event/command 模式 - 如果接口开始依赖具体 struct（如
func (u *User) DoX()），说明契约太重，得精简或拆分
共享结构体（如 User、Order）该放哪
两个包都要用 User，但互相 import 就会死锁。复制粘贴更糟——字段一改，全项目散落的副本全得同步。
- 新建独立包，如
model或domain，只放struct、const、var ErrXXX error，**不写任何 method，不 import 任何业务包** - 验证它是否干净：运行
go list -f '{{.Imports}}' ./domain，输出应为空，或仅含errors、time等标准库 -
user.Service和order.Repository都 importdomain，但彼此不 import ——依赖树变成单向发散 - 禁止在
domain.User里加业务逻辑方法，比如SendWelcomeEmail()，那等于让 domain 反向依赖 notification
什么时候该合并包，而不是硬拆
不是所有循环都靠抽象能优雅解决。有些场景，强行分包只会增加无谓的跳转和包数量。
- 当两个包的类型**必须互相嵌套**且**生命周期完全绑定**时，比如
Person和Team中各自持有对方指针，且从不单独使用——合并进models更合理 - 当拆出的
contract包开始被十几个业务包 import，且里面接口方法签名越来越臃肿（比如一个UserProvider接口塞了 8 个方法），说明边界划错了，应回头审视领域上下文 -
internal/不是用来“绕过”循环的，但它能帮你识别哪些本不该导出的逻辑被误用了——如果只有internal/validator被多个业务包 import，而它们本该共用上层domain，那就暴露了分层失当
最易被忽略的一点：循环依赖往往不是代码写错了，而是业务边界模糊了。比如 user 包里出现订单状态变更逻辑，或 payment 包里直接查用户地址——这时重构重点不在接口怎么写，而在先厘清“谁该负责什么”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
