go编译器静态遍历import图时发现闭环（如a→b→a）立即报错终止，不支持前向声明或延迟解析；解法是提取接口到独立contract/port包，或改用函数参数传依赖。
为什么 import cycle not allowed 一出现就编译失败
Go 编译器在解析 import 图时是静态、一次性遍历的，只要发现 A → B → A 这样的闭环，立刻终止。它不支持前向声明、不延迟解析接口实现，也不允许“先定义后导入”。这不是警告，是硬性拒绝——哪怕两个包只通过接口类型间接耦合，只要 import 图闭合，就报错。
常见错误现象：import cycle not allowed 后跟着一串包路径，比如 main imports pkgA imports pkgB imports pkgA；或者更隐蔽的：A 定义了接口，B 实现它并 import A，A 又 import B 来调用该实现（典型反模式）。
- 别把接口和它的实现放在同一个包里又互相 import —— 接口应由使用者定义，或提前提取到第三方契约包
- 避免在
models包里 importhandlers或services来“方便调用”，这是循环温床 - Go 没有“接口声明可跨包延迟绑定”的语法糖，
interface{}不是解药，它只是空接口，不解决依赖方向问题
把接口移到独立的 contract 或 port 包里
这是最直接、Go 官方示例（如 net/http 的 Handler 接口）也采用的做法：把抽象契约抽成最小公共包，让上下游都 import 它，但彼此不直连。
使用场景：微服务间 DTO 共享、领域层与 infra 层解耦、测试 mock 需要稳定接口签名。
立即学习“go语言免费学习笔记（深入）”；
- 新建
pkg/port（或pkg/contract），只放type Service interface { ... }和必要struct（如 request/response） -
pkg/coreimportpkg/port定义业务逻辑，但不 import 任何具体实现 -
pkg/infra/db和pkg/infra/http都 importpkg/port，各自实现接口，且互不 import - 注意：这个包不能 import 任何下游包（如
db或http），否则又绕回循环
用函数参数传入依赖，而不是包级变量或 init 初始化
很多循环源于想“全局可用”——比如在 models/user.go 里直接调用 cache.Get()，而 cache 又 import models 做序列化。这时不是加个接口就行，而是得重构调用时机。
性能影响很小：函数参数传递接口值是零拷贝（底层是 iface 结构体，2 个指针大小），比反射或 map 查找快得多。
- 把原本写死的依赖调用，改成函数签名里显式接收，例如：
func (u *User) Save(db DBer) error而非func (u *User) Save() error - 避免在
init()函数里初始化跨包依赖，init 是包加载时执行，会强制提前触发 import 链 - 如果必须封装一层（比如统一错误处理），用闭包或 struct 字段存依赖，而非包级变量
小心测试文件引发的隐式循环
xxx_test.go 文件属于同一个包，但它能 import 当前包的内部符号；而如果测试文件又 import 了本不该被该包依赖的其他包（比如 user_test.go import mockdb，而 mockdb import user），就会悄悄引入循环。
常见错误现象：主代码能编译，但 go test ./... 报 import cycle；或者 go build 成功，go run main.go 却失败。
- 测试文件应尽量只 import 被测包 + 标准库 + 纯数据 mock（如
github.com/stretchr/testify/mock），避免 import 其他业务包 - mock 实现不要放在业务包里（比如
pkg/db/mock.go），应放在pkg/db/mocks/下，并确保该目录不被业务包 import - 用
//go:build unit或单独构建 tag 控制测试依赖，比靠目录名更可靠
真正麻烦的不是怎么拆，而是哪些地方看似无关却悄悄连上了——比如一个日志中间件引用了用户 ID 格式校验函数，而校验函数又 import 了配置包，配置包 init 时读了数据库连接……这种链式依赖，得用 go list -f '{{.Deps}}' xxx 一层层扒 import 树才能看清。
