go中循环引用在编译期报错，需用go list -f '{{.deps}}'定位import环；解决关键是提取公共契约包并遵循“接口由调用方定义”原则。
循环引用在Go里根本不会编译通过
Go 编译器会在构建阶段直接报错，比如 import cycle not allowed 或更具体的 import "xxx": import cycle not allowed。这不是运行时问题，也不是设计模式层面的“逻辑循环依赖”，而是包级 import 语句形成的环路。所以重构的第一步不是改代码结构，而是定位哪个 import 链触发了环。
用 go list -f '{{.Deps}}' 快速定位 import 环
手动翻 import 链容易漏掉间接依赖。执行命令能一次性展开整个依赖图：
go list -f '{{.Deps}}' your/module/path
如果输出里出现自身路径（比如 your/module/path 出现在自己的 Deps 列表中），就说明存在 import cycle。常见场景包括：
-
pkg/a导入pkg/b，pkg/b又导入pkg/a -
pkg/a→pkg/b→pkg/c→pkg/a（三跳环） - 某个
internal/子包被外部包意外引用，又反向依赖外层
拆包策略：把共享类型/接口提到公共包
90% 的循环引用源于两个包互相需要对方的 struct 或 interface。典型例子是 service 包要调用 model 包的类型，而 model 包又嵌入了 service 定义的回调接口。解决方式不是删 import，而是提取契约：
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
- 新建
contract/或types/包（不依赖其他业务包） - 把共用的
type User struct、type UserRepository interface移进去 -
service和model都只 importcontract，不再互相 import
注意：不要把实现细节（如数据库字段标签、HTTP 序列化逻辑）放进公共包，否则会污染边界。
interface 定义必须放在调用方，而不是实现方
一个经典错误是让 model 包定义 type Storer interface { Save() }，然后 service 实现它——这会导致 model 依赖 service。正确做法是：
-
service包定义type UserStorer interface { SaveUser(u *User) error } -
model包提供具体类型type UserModel struct - 在
main或cmd层做组合：svc := NewService(&UserModel{})
这样 model 完全无 interface 依赖，service 也不需要知道 UserModel 的内部结构，只认自己定义的契约。
真正麻烦的不是怎么拆，而是团队里有人偷偷在 internal/ 下建了个工具函数，又从根目录包 import 了它——这种隐式依赖很难 grep 出来，得靠 go list 配合 go mod graph 交叉验证。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
