Go中import cycle报错本质是包级import图闭环，非运行时接口调用问题；正确解法是将接口与共享类型抽离至独立contract包，确保其无业务依赖，并由main层注入实现。
Go 里根本不存在“接口循环调用”这种合法行为——import cycle not allowed 报错永远是包级 import 图闭环导致的，不是运行时接口调用的问题。所谓“接口循环调用”，其实是开发者误把“两个包通过接口互相依赖对方实现”当成了可接受的设计，而 Go 编译器只看 import 路径，不区分你是调接口还是调函数。
为什么定义了接口还是报 import cycle
常见错误是把接口定义在 A 包里，B 包去 import A 实现它；同时 A 包又 import B 来获取那个实现。结果就是：
- A → B（为了拿到实现）
- B → A（为了导入接口）
这仍是标准的 import cycle。接口只是解耦手段，不是免死金牌——关键在于接口放在哪、谁 import 谁。
正确做法：interface 必须放在双方都可 import 但又不 import 彼此的第三方包中（如 contract、types 或 internal/contract），且该包自身不能有对外部业务包的 import。
如何验证 contract 包真的“干净”
执行这条命令检查它是否引入了不该有的依赖：
go list -f '{{.Imports}}' ./internal/contract
输出应为空，或仅含 errors、time 等标准库。如果出现 github.com/your/app/service 这类路径，说明它偷偷依赖了业务包，必须删掉。
另外注意：internal/ 包只能被其父目录及子目录下的包 import，不能被外部模块引用——这是 Go 官方机制，不是命名约定。
回调场景下最容易踩的坑：函数字段 vs 接口注入
当 service A 需要通知 event B，而 B 处理完又要回调 A 时，别这么写：
- 在 A 包里定义
type Callback func(...)，然后 B 包import A来调用它 - 或在 B 包里定义接口，让 A 实现，结果 A 又得
import B来传实现
这两种都绕不开 import cycle。真正安全的做法是：
- 回调契约（哪怕只是一个
func类型）必须定义在contract包里 - A 的结构体里声明字段为
OnDone contract.DoneFunc，不写具体实现 - B 不 import A，只 import
contract，并在需要触发回调时调用c.OnDone(...) - 组装逻辑全交给
main或cmd/：由它 new A、new B，再把 A 的某个方法赋给 B 的回调字段
重构后仍报错？优先检查测试文件
很多团队在 xxx_test.go 里偷偷加了反向 import，比如 user/repo/user_repo_test.go 为了测集成，直接 import "myapp/user/service"，而 service 又 import repo —— 测试代码也是编译图的一部分。
临时验证方式：删掉所有 *_test.go 文件，再跑 go build。如果成功，问题就出在测试文件里。长期方案是把集成测试放到单独的 integration/ 目录下，避免污染主包依赖图。
最隐蔽的点是：循环未必发生在你刚改的两个包之间，可能经由 utils、middleware 或 config 这类“看似无害”的包中转。用 go mod graph | grep your-module 搭配人工追踪，比靠直觉更可靠。
