go禁止import循环，编译期即报错；解法是提取公共接口到独立包或改用回调注入，replace和构建标签均无效。
为什么 import 两个包会直接报错 “import cycle not allowed”
Go 编译器在构建阶段严格禁止任何 import 循环，哪怕只是 A → B → A 这种间接依赖。它不靠运行时解析，而是在语法树分析阶段就拒绝编译，所以你不会等到链接或运行才看到问题。
常见错误现象：import cycle not allowed: main imports pkgA imports pkgB imports pkgA。注意错误里列的是完整路径，不是文件名——说明循环发生在 package 级别，和文件数量无关。
- 不是“写了循环引用的代码才出错”，而是只要 import 图里存在环，
go build就立刻失败 - 即便两个包只互相导出一个空接口、甚至只 import 但没用到任何符号，也会触发
-
_或.导入方式不能绕过检查；import _ "xxx"同样参与 cycle 判定
拆分接口：把共用类型提到第三个包里
最常用也最干净的解法是引入中间包，把双方都依赖的类型（尤其是 interface）抽出来。这不是“多此一举”，而是 Go 强制你显式声明契约边界。
使用场景：比如 pkgA 定义了 type Processor interface{ Do() }，pkgB 实现它，但又需要把实现传回 pkgA 调用——此时两者必须共享这个 interface 定义。
立即学习“go语言免费学习笔记（深入）”；
- 新建
pkgC（如types或contract），只放 interface 和基础 struct，不 import 其他业务包 -
pkgA和pkgB都 importpkgC，不再互相 import - 避免把逻辑也塞进
pkgC：它应该只有类型定义，没有函数实现或 init 逻辑
示例：pkgA/foo.go 中写 import "myapp/types"，然后声明 func Run(p types.Processor)；pkgB/bar.go 同样 import types 并实现该 interface。
重构调用方向：用回调或参数注入代替反向依赖
当 A 需要调用 B 的某个功能，而 B 又“不得不”调用 A 的某个函数时，其实不是 B 真的需要 A，而是 A 没把可变行为抽象出来。
性能 / 兼容性影响：这种改法不增加包数量，也不改变调用栈深度，反而让依赖更清晰、单元测试更容易 mock。
- 把 A 中被 B 调用的函数改成函数类型参数，例如
func Process(data string, onDone func(result string)) - B 不再 import A，只接收 A 传来的回调函数值
- 如果回调逻辑复杂，可封装为 interface，再按前一节方式提到独立包
- 警惕“为了破循环硬塞一个空 interface{} 参数”——这会让调用方失去类型安全
go.mod replace 和本地路径不是解决循环依赖的办法
replace 是用于覆盖远程依赖版本或调试 fork 分支，它完全不干预 import cycle 检查。即使你用 replace ./pkgA => ./pkgA-fix，只要 import 图里还有环，编译照样失败。
容易踩的坑：
- 误以为
go mod tidy能自动修复循环——它只会报错并退出 - 试图用
//go:build ignore或构建 tag 把某个 import “临时屏蔽”——cycle 检查发生在构建 tag 解析之前 - 在
main包里用匿名 import（import _ "xxx"）想“悄悄引入”——一样计入 cycle
真正能绕开 cycle 的只有两种情况：彻底打破 import 图，或者把循环部分合并进同一个 package（但通常意味着设计退化）。
最麻烦的地方往往不在循环本身，而在于两个包已经各自积累了大量外部依赖，导致拆接口时要同步调整十几个地方的 import 路径——这时候别省那几秒，老老实实 grep + sed，比猜哪个 type 该放哪更可靠。
