import cycle not allowed 错误无法靠调整import顺序解决，因为go在编译前期检查循环依赖，只要两包互相import即报错，与执行顺序、函数调用与否无关。
为什么 import cycle not allowed 错误无法靠“换个 import 顺序”解决
Go 的 import cycle 检查发生在编译前期，和代码执行顺序无关。只要两个包互相 import，哪怕只有一行 import "pkgA" 在 pkgB 里、反过来也有一行，立刻报错——它不看函数是否实际调用，也不管变量是否声明后未使用。
常见错误现象是：删掉某个 import 后编译通过，但功能崩了；或者把函数挪到另一个文件，以为“物理隔离”就能绕过，结果还是报同样的 cycle 错误。
- Go 不支持前向声明，接口不能跨包定义后直接被实现方引用
- 类型别名（
type MyErr = errors.Err）若跨包使用，仍需 import 原包，可能隐式引入依赖 - 测试文件（
_test.go）如果 import 了被测包又反向 import 测试辅助包，也会触发 cycle
用接口 + 依赖注入打破 import cycle 的实操路径
核心不是“删 import”，而是把强依赖变成弱契约。让 A 包依赖一个接口定义，而该接口的实现放在 C 包，B 包再把实现传给 A——这样 A 和 B 都只 import C，不再互指。
典型场景：服务层（service）需要调用仓储层（repo），但 repo 又要调用 service 做回调或状态更新。
立即学习“go语言免费学习笔记（深入）”；
- 在独立的
contract或domain包中定义接口，如type Notifier interface { Notify(...) -
service包只 importcontract，并接收Notifier作为构造参数（而非在内部 new 或 importrepo） -
repo包实现Notifier，并 importcontract和具体业务类型（如model.User），但不 importservice - main 或 wire 初始化时，把
repo的实例传给service构造函数
示例关键片段：
func NewUserService(n contract.Notifier) *UserService { return &UserService{notifier: n} }
internal 目录不是万能解药，但它能帮你识别“本不该导出”的循环
把本该私有的逻辑放到 internal/ 下后，外部包根本无法 import 它——这会强制你暴露更干净的边界。很多循环其实源于过早导出工具函数、中间件或 DTO 结构体。
使用场景：多个业务子包（auth/、payment/）都依赖同一个校验逻辑，结果各自 copy 一份或互相 import 工具包。
- 把共用校验逻辑放进
internal/validator，只允许同级或子目录 import - 如果
auth/和payment/都需要它，说明它们应该共享上层 domain 包，而不是彼此耦合 -
internal下的包仍可相互 import，所以不能用来“绕过 cycle”，只能帮你发现设计漏洞 - 注意
go list -f '{{.Imports}}' ./auth可快速查看真实 import 树，确认是否意外引入了internal/payment
重构时最容易被忽略的隐式依赖：全局变量、init 函数、嵌入结构体
你以为只是改了 import，但 init() 函数会在包加载时自动执行，如果它调用了其他包的函数，就构成了隐式 import 依赖；嵌入结构体（type A struct{ B }）也会把 B 的方法提升到 A，导致 A 所在包必须 import B 的包。
- 检查所有
init()函数，把副作用逻辑移到显式初始化函数中（如SetupDB()），由上层控制调用时机 - 避免跨包嵌入结构体；如需复用行为，用组合+接口替代（
type A struct{ b Ber }，其中Ber是接口） - 全局变量（尤其是
var db *sql.DB）常被多个包直接引用，应改为通过参数或配置中心注入 - 用
go mod graph | grep 'pkgA.*pkgB\|pkgB.*pkgA'能暴露间接依赖链，比如pkgA → utils → pkgB
真正卡住重构的，往往不是 import 语句本身，而是那些没写在 import 行里、却让两个包事实绑定的代码习惯。
