go禁止模块间循环导入，因编译期依赖图必须为有向无环图（dag），一旦检测到a→b→a闭环即报import cycle not allowed错误；需通过接口解耦、抽离shared/contract包、依赖倒置等设计手段从源码层面切断循环。
模块间相互嵌套调用本身不是问题，但若缺乏分层约束和依赖方向控制，就会立刻触发 import cycle not allowed 编译错误，根本跑不起来。
为什么嵌套调用会直接编译失败
Go 编译器在解析 import 时就做拓扑排序，一旦发现 A → B → A 这类闭环，立即中止。它不等运行、不延迟加载、不靠反射绕过——这是硬性限制，不是配置能关掉的。
- 错误信息通常形如：
import cycle not allowed: github.com/x/a imports github.com/x/b imports github.com/x/a - 哪怕只是两个包互相
import，哪怕只有一行函数调用，也报错 - 不是“逻辑混乱”，而是“结构非法”：Go 要求依赖图必须是有向无环图（DAG）
用接口解耦代替直接 import
把跨模块调用从“包级依赖”降级为“契约依赖”，是唯一稳定解法。关键不是让 A 调用 B 的函数，而是让 A 定义它需要什么能力，B 去实现它。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- A 包内定义
type PaymentProcessor interface { Charge(amount int) error }，不 import B - B 包实现该接口，
importA（单向依赖），但不暴露具体类型给 A - A 在运行时接收一个
PaymentProcessor实例（比如通过构造函数注入），不关心它来自哪个包 - 避免把接口定义在 B 包里——否则 A 还是得 import B，没解决问题
抽离 shared 或 contract 包强制分层
当多个模块都用到同一组结构体、错误码或常量时，硬塞进某一个模块只会加剧耦合。必须把它们拎出来，放在比所有调用方都“高”的位置。
- 新建
pkg/contract或internal/types，只放 interface、struct、error code - 这个包不能 import 任何业务模块（A、B、C 都不行），只能被它们 import
- A 和 B 都 import
pkg/contract，各自实现其中定义的行为，彼此不再直连 - 如果已有循环，先删掉 A ↔ B 的 import，再把共用部分迁出，最后补上对
pkg/contract的引用
replace 指令只用于开发，上线前必须清理
在多模块单仓库项目中，replace 是调试利器，但也是版本冲突的温床。它会让本地路径覆盖模块路径，导致 go mod graph 看不见真实依赖链。
- 开发时写：
replace github.com/my/project/service-a => ./internal/service-a - CI 流程中必须检查
go mod edit -json | jq '.Replace'是否为空，非空则拒绝合并 - 上线构建前运行
go mod edit -dropreplace=github.com/my/project/service-a，还原为语义化版本引用 - 别指望
replace能绕过循环依赖——它只是改路径，不改 import 关系，编译照样挂
真正麻烦的从来不是怎么调用，而是谁该依赖谁。只要依赖方向错了，再多的包装、中间件、事件总线都救不了——Go 会在编译第一秒就把它拦下来。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
