Go 的 import 机制在编译期严格禁止循环依赖，无法绕过，必须通过接口抽象、分层解耦和契约先行等重构手段解决。
为什么 go build 报 “import cycle not allowed” 就得重构，不能绕过去
Go 的 import 机制在编译期就拒绝循环依赖，不是运行时报错，也不是警告——它直接中断构建。这意味着你没法用条件导入、延迟加载或 mock 包来“骗过”编译器。只要 A 导入 B，而 B 又间接或直接导入 A（哪怕隔着三层），go build 就会立刻失败。
常见诱因包括：把 domain 模型和 repository 实现塞进同一个包；在 service 层直接 new 一个 db 操作 struct 并调用其方法，而该 struct 又引用了 service 中定义的回调函数；或者为了“方便”把 config 初始化逻辑和 HTTP handler 放一起，结果 handler 依赖 config，config 又要读路由配置。
- 别试图用
_导入或空 import 来“占位”——无效，且会让后续维护者更难定位依赖链 - 别把接口和实现放在同一包里，尤其当接口方法参数或返回值是本包其他类型时，极易触发隐式循环
-
go list -f '{{.Deps}}' ./pkg/a可快速展开依赖树，但注意它不显示跨包的接口实现绑定关系，得人工追
把接口提到独立包里，但别叫 interfaces
单纯建个 interfaces 包并把所有 type Xer interface 往里搬，反而容易造成新循环：比如 user.Service 依赖 interfaces.UserRepo，而 interfaces.UserRepo 方法签名里用了 user.Model —— 这时 interfaces 就不得不导入 user，又绕回去了。
真正有效的做法是让接口包只依赖它“必须知道”的最小类型集，通常只有 Go 内置类型、error、context.Context，以及它自己定义的 DTO 或 ID 类型。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 接口包名应反映领域契约，例如
payment（含Charger,Refunder），而不是抽象名词interfaces - 模型类型（如
User,Order）若需被多个包共用，应单独抽成model或domain包，并确保它不依赖任何业务逻辑包 - 接口方法参数尽量用指针或值类型传参，避免接收方包里的具体 struct；必要时定义轻量 DTO，例如
type CreateUserReq struct { Name string }，放在接口包内
repository 实现怎么和 domain 解耦，又不写一堆 adapter
典型错误是让 user.Repository 直接返回 *user.User，导致调用方（如 user.Service）必须导入 user 包；而 user.User 如果又嵌套了 user.Address 等子结构，整个依赖网就拧死了。
解法不是加一层泛型 adapter，而是用“契约先行 + 类型转换下沉”：接口定义在 user 包外（如 useriface），方法返回 useriface.User（一个只含 ID/Name 的精简 interface），而具体实现（如 pgrepo.UserRepo）在内部把 DB 查询结果转成该 interface 的匿名 struct 实例。
- 不要在
pgrepo包里 importuser；它的 struct 可以叫pgUser，实现useriface.User，但字段命名、序列化逻辑全在自己包内控制 - 如果 domain 层需要校验逻辑（如
User.IsValid()），把它作为方法挂在useriface.User上，由接口包提供默认实现（用组合或 embed），而非要求实现包重复写 - 避免为每个 repo 都建独立包；可按数据源聚类，例如
repo/pg放所有 PostgreSQL 实现，repo/mem放内存 mock，它们都实现同一组xxxiface接口
重构时怎么验证没漏掉隐式依赖
光看 import 语句不够。Go 允许跨包使用未导出字段的反射、unsafe 指针，或通过 interface{} 传递具体类型，这些都会在运行时才暴露循环问题，但编译期沉默。
最可靠的方式是分阶段隔离编译：先删掉所有业务逻辑包，只留 model 和 xxxiface，确认能编译；再逐个加入 service、pgrepo，每次加完跑 go build ./...；最后补上 cmd 和 http 层。
- 启用
GO111MODULE=on go mod vendor后检查vendor/目录结构，循环依赖会导致某些包缺失或路径异常 - 用
go mod graph | grep 'pkgA.*pkgB\|pkgB.*pkgA'快速扫描双向依赖线索 - 如果某个包里大量使用
func(x interface{})并在内部做x.(*somePkg.Type)类型断言，这就是隐式强依赖，必须改成显式接口或 DTO
最难处理的其实是测试文件里的循环：比如 service_test.go 为了 mock repo，直接 import pgrepo，而 pgrepo 又 import service 做回调——这种往往藏在 test 文件里，主代码看着干净，一跑测试就崩。
