必须立刻改结构，因为Go编译期严格禁止import循环，遇到A→B→A等路径直接失败退出，无法通过配置、接口抽象或延迟加载绕过，只能从包依赖图层面重构。
为什么 go build 报 “import cycle not allowed” 就得立刻改结构？
Go 的模块系统在编译期就严格禁止 import 循环，不是警告，是硬性失败。它不像某些语言能靠运行时或接口抽象绕开——go build 一碰到 A → B → A 这类路径，直接退出，连中间产物都不留。这不是配置能调的，必须从包依赖图上动手。
常见触发场景：两个业务包互相调用核心函数；models 包里定义结构体，又在同个包里写数据库操作（隐式依赖 database/sql）；或者把工具函数和领域逻辑混在一个包里，结果被两边同时 import。
- 别试图用
_导入或空导入“骗过编译器”——没用，循环在 AST 解析阶段就被捕获 - 接口不能解决根本问题：哪怕你把依赖改成 interface，只要实现类型还在原包里、且被对方 import，循环照旧
- 最隐蔽的坑是间接循环：A → B，B → C，C → A，
go list -f '{{.Imports}}' ./...可以辅助排查
怎么拆出一个 internal 包来切断循环？
把被多方依赖的纯数据定义、共享错误类型、基础工具函数拎出来，放进 internal 子目录，是 Go 官方推荐且最稳妥的解法。它天然阻止外部模块 import，又能被同项目内所有包访问。
比如原本 user 和 order 包都定义了 ErrNotFound，还各自写了 ValidateEmail()，这就是典型的可提取点。
- 新建
internal/common，放errors.go（统一错误变量）、validation.go（校验函数） - 删掉
user/和order/里重复的定义，改用import "myapp/internal/common" - 确保
internal/不在go.mod的replace或require列表里——它不属于模块依赖，只是项目内部组织手段 - 注意：如果已有其他模块依赖你的
user包，而它暴露了本该私有的类型，那先加//go:build !unit注释或重命名字段，再拆
go mod graph 看到几十行输出，怎么快速定位循环链？
go mod graph 输出的是全量依赖边，人眼扫太慢。真正有用的命令是：go list -f '{{.ImportPath}}: {{.Imports}}' ./...，再配合 grep 锁定可疑包。
假设你怀疑 user 和 notification 有循环，可以：
- 运行
go list -f '{{.ImportPath}} -> {{.Imports}}' ./user ./notification | grep -E "(user|notification)" - 看输出里有没有
user -> [ ... notification ... ]同时又有notification -> [ ... user ... ] - 更准的办法：用
go mod graph | grep -E "(user|notification)" | grep -E "(user.*notification|notification.*user)" - Windows 用户注意：
go mod graph在 PowerShell 里默认换行符不同，建议用 WSL 或 Git Bash 执行
能不能用 init() 或闭包延迟加载躲过循环？
不能。Go 的 import cycle 检查发生在包加载阶段，早于任何 init() 执行。就算你把函数包装成 func() error 类型、存在变量里，只要 import 语句存在，编译就失败。
有人试过把依赖包路径拼成字符串、用 plugin.Open() 动态加载——这不仅破坏编译时检查，还会让二进制体积暴涨、无法交叉编译、调试困难，属于用错工具。
- 唯一合法的“延迟”是把逻辑下沉到函数参数里：比如
ProcessOrder(order Order, sender NotificationSender)，而不是在包顶层 importnotification - 如果真需要运行时解耦，考虑定义明确的 interface 放在
internal/contract，让双方都只依赖它，不依赖彼此实现包 - 记住：循环依赖本质是职责不清。花 20 分钟画个简笔依赖图，比改十次代码更省时间
internal ——这个边界感，得看三次 PR 才能拿稳。 
