Go编译器遇循环依赖直接报import cycle not allowed并终止构建，必须重构依赖结构；可用go list -f '{{join .Deps "\n"}}'定位间接环路，将共用类型提至独立domain包，接口定义置于调用方或上层包，通过依赖注入解耦实现。
Go 编译器遇到循环依赖会直接报 import cycle not allowed，没有商量余地——这不是警告，是硬性终止。解决它不是绕过限制，而是重构依赖结构。
用 go list -f '{{join .Deps "\n"}}' <包路径> 定位真实环路
别靠猜。循环往往藏在间接依赖里（A → B → C → A），go mod graph 输出太长难读，go list 更精准：
- 先复现错误，记下报错中提到的两个包路径（比如
example.com/user和example.com/order） - 对其中一个运行
go list -f '{{join .Deps "\n"}}' example.com/user，看它到底 import 了哪些包 - 再顺藤摸瓜查那个“不该出现”的包是否反向 import 了起点——比如发现
example.com/order里有import "example.com/user" - 注意：vendor 或
replace可能导致路径解析错乱，临时删掉go.mod里的replace再试
把共用类型/接口提到独立包，而不是塞进任一业务包
最常见诱因是：service 包和 repo 包都直接用了 User 结构体，结果一个放 service 下、一个放 repo 下，彼此 import —— 这本质是职责错位。
-
User、OrderID、ErrInvalidInput这类东西不属于任何业务逻辑层，应单独建model或domain包 - 业务包只 import 这个新包，不再互相 import；例如
service/user.goimport"example.com/model"，repo/mysql.go也只 import 同一个model - 避免命名陷阱：别叫
common（太泛，容易被滥用成垃圾桶），用domain或types更明确边界 - 这个包里不能 import 任何业务包（
service、repo、handler），否则环又回来了
用接口 + 依赖注入切断具体实现的反向引用
当 A 需要调用 B 的某个能力，B 又需要回调 A 的状态或方法时，直接 import 就形成环。解法不是删掉调用，而是反转依赖方向。
立即学习“go语言免费学习笔记（深入）”；
- 在 A 包里定义接口（如
type Notifier interface { Notify(string) }），不 import B - B 包实现该接口，import A（仅为了引用接口类型，不 import A 的实现逻辑）
- A 在运行时接收一个
Notifier实例（通过构造函数参数或SetNotifier()方法），不硬编码依赖 B 的包路径 - 关键点：接口定义必须在调用方（A）包内，或更上层的
domain包；实现方（B）只实现，不定义 - 测试时可直接传入 mock 实现，不用启动真实 B 模块
警惕 internal 包被误用为“临时解耦工具”
internal 能阻止外部引用，但解决不了环——如果 a/internal/util 同时被 a/service 和 a/repo import，而这两个包又互相 import，环依然存在。
-
internal只适合收拢**纯工具函数**（如ParseJSON、RetryHTTP）或**仅被同级包使用的中间类型** - 一旦
internal包里出现业务逻辑、领域模型或跨层接口，就等于把环从包级挪到了目录级，问题没变 - 真正要拆的不是路径，是抽象层级：把“做什么”（接口）和“谁来做”（实现）物理隔离
最难的不是找到环，而是说服自己：那个“顺手调一下对方函数”的设计，其实是职责不清的信号。重构时盯着 import 语句改，不如先问一句——这个类型/行为，到底属于哪个抽象层？
