go编译器对循环依赖报错且不指明路径，需用go mod graph或go list定位；接口应置于中立包如internal/port；抽离公共代码须遵循契约性、只读性原则，并注意符号变更的连锁修改。
Go 编译器遇到循环依赖会直接报 import cycle not allowed，没有绕过办法，只能重构。这不是 bug，是设计强制你理清依赖方向。
怎么快速定位循环依赖路径
编译器只报错，不指明哪条链成环。靠手动翻 import 很容易漏掉间接依赖（比如 A → B → C → A）。最有效的是用 Go 自带工具画出依赖图：
-
go mod graph | grep -E 'pkgA|pkgB'—— 快速筛出可疑包之间的边，一眼看出回边（如pkgA → pkgB → pkgA） -
go list -f '{{.ImportPath}} -> {{join .Imports " -> "}}' ./... | grep pkgA—— 查看所有含 pkgA 的导入链，确认它被谁引入、又引入了谁 - 别忽略
_test.go文件：测试文件可能偷偷 import 了生产代码，又被生产代码反向 import，这种隐式环最难发现 - 检查
//go:embed或//go:generate生成的代码，它们可能悄悄引入了源包
接口解耦时接口该放哪儿
接口位置错了，反而加深耦合。关键原则：接口定义必须放在「调用方和实现方都不拥有」的第三方包里，且这个包不能 import 任何业务实现包。
- ❌ 不要放在调用方包里（比如
service包定义Repo接口，再让repo包去实现 —— 这会让repo被迫 importservice） - ❌ 不要放在实现方包里（比如
repo/sql定义UserRepo接口，service包 import 它 —— 这等于暴露了实现细节） - ✅ 推荐放在
internal/port或pkg/contract这类中立包里，只包含接口、DTO、错误类型，且不 importservice或repo - 示例：
service依赖port.UserRepo，repo/sql实现port.UserRepo，两者都只 importport，无交叉
提取公共部分到新包的实操要点
不是所有共用代码都适合抽离，抽错地方反而增加维护成本。重点抽那些「双方都只读、不修改」的契约性内容：
- 优先抽：DTO 结构体（如
type User struct{...}）、核心接口、错误变量（var ErrNotFound = errors.New("not found")） - 谨慎抽：工具函数（如
util.Stringify），除非多个包真正在语义上共用同一逻辑；否则容易变成“万能 utils”，后期难以拆分 - 新建包名要有明确语义，比如
pkg/domain（领域模型）、pkg/identity（身份相关抽象），避免叫common或shared这种空泛名 - 确保新包不 import 任何业务包 —— 如果
pkg/domain里 import 了service，那只是把循环从 A↔B 换成了 A↔domain↔B
真正卡住重构的从来不是语法或命令，而是符号可见性变更后，调用处的类型断言、字段访问、方法签名全得同步改。一个 model.User 变成 domain.User，所有赋值、比较、JSON 序列化点都得动，这点容易被低估。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
