最有效的是用go list和go mod graph配合过滤：go list -f '{{.importpath}} -> {{join .imports " -> "}}' ./输出导入链再grep搜包名，或go mod graph | grep -e 'pkga|pkgb'筛回边；注意_test.go、embed、generate可能隐式引入循环，接口须定义在双方都不拥有的第三方包中。
go build 报 import cycle not allowed 怎么快速定位
编译器只报错不指路，得靠工具自己挖。最有效的是用 go list 和 go mod graph 配合过滤：
-
go list -f '{{.ImportPath}} -> {{join .Imports " -> "}}' ./输出所有包的导入链，再用grep搜可疑包名（比如grep "user"），一眼看出 A → B → user → A 这类回边 -
go mod graph | grep -E 'pkgA|pkgB'更快，直接筛出两个包之间的路径，若出现pkgA pkgB和pkgB pkgA并存，就是闭环 - 别忽略
_test.go文件——测试代码常偷偷 import 生产包，又反过来被生产包 import，这种隐式环最难发现 - 用了
//go:embed或//go:generate？生成的代码可能悄悄 import 回源包，要检查生成结果
接口该定义在哪个包里才不会引发新循环
接口放错位置，等于把循环从“包级”挪到“语义级”。关键原则：接口必须定义在「双方都不拥有」的第三方位置，且该包不能反向 import 任何业务实现。
- 不能放在调用方包里（比如
service定义UserRepo接口）——这会让repo包为实现它而 importservice - 不能放在实现方包里（比如
repo/mysql定义UserRepo）——这会让service不得不 importrepo/mysql才能用接口，暴露了具体实现 - 推荐放在
internal/port或pkg/contract这类共享包中，它只含接口、DTO、错误类型，且go list -deps检查时，这个包的.Imports应为空或仅含std包 - 如果项目小，直接提成
pkg/types也行，但务必确认里面没混入任何逻辑函数或 init 调用
合并包还是抽离公共层：什么情况下该选哪条路
不是所有循环都适合抽象接口——有些只是职责本就该在一起，硬拆反而增加间接层。
- 当两个包互相引用的是同一组领域模型（比如
user和team中的结构体互嵌），且没有外部消费者依赖它们的分离形态，直接合并为pkg/domain最干净 - 当循环源于跨层调用（比如
handler直接调repo/mysql，而repo/mysql又 importhandler做日志回调），必须抽离接口 + 依赖注入，合并只会掩盖问题 - 如果已有其他包依赖其中一方（比如
api包 importuser），那user就不能和team合并，否则破坏 API 稳定性 - 注意
internal/包的使用边界：它能隔离共享逻辑，但一旦internal/utils开始 importservice或model，就又绕回去了
依赖注入时容易忽略的初始化顺序陷阱
用 NewXxx(...) 传依赖看似解耦，但若构造函数里立刻调用依赖方法，仍可能触发隐式循环。
- 避免在构造函数中执行业务逻辑，尤其是调用传入依赖的方法（如
svc := NewService(repo); svc.Init()中Init()调repo.Ping()） - 把依赖注入和启动逻辑分开：构造函数只存依赖，用单独的
Start()或Run()方法触发实际调用，由main统一控制顺序 - 警惕全局变量或
init()函数——它们在 import 时就执行，会绕过你精心设计的依赖注入时机 - 如果用 Wire/Dig，检查生成代码是否真的把所有依赖都作为参数传入，而不是在生成的
injector.go里偷偷 import 了业务包
go build ./ 和 go list -deps，而不是只看 IDE 是否报红。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
