Go 的 import 循环直接报错是因为编译器在构建阶段就进行导入图分析，要求依赖必须单向无环；解决方式是通过接口解耦、抽离契约到独立包、依赖注入及避免隐式依赖。
为什么 Go 的 import 循环会直接报错而不是延迟解析
Go 编译器在构建阶段就做完整的导入图分析，import 不是运行时行为，一旦发现 A → B → A 这样的路径，立刻报 import cycle not allowed。它不像 Java 或 Python 那样允许模块级变量或函数的前向引用——Go 要求所有依赖必须是单向、无环的。
所以“用接口解除循环依赖”本质不是绕过 import 规则，而是把强耦合的类型依赖，降级为弱耦合的契约依赖，并把具体实现移出 import 路径。
把具体实现抽到第三方包，让双方只 import 接口定义
这是最干净的做法：新建一个 contract 或 domain 包，只放 interface 定义和通用 DTO，不放任何实现逻辑。A 和 B 都 import 它，但彼此不互相 import。
-
contract/user.go里定义type UserRepo interface { GetByID(id int) (*User, error) } - A 包（比如
service）importcontract，并接收UserRepo作为参数，不关心谁实现它 - B 包（比如
repo）也 importcontract，并实现UserRepo - main.go 或 wire.go 中 new 具体实现，然后注入到 service 中
这样 A 和 B 的 import 图变成：A → contract ← B，环被打破。
立即学习“go语言免费学习笔记（深入）”；
用函数参数或字段注入接口，避免包级全局依赖
常见错误是写 var repo *UserRepoImpl 在包顶层，导致 import 环；正确做法是把依赖“推下去”，通过构造函数或方法参数传入。
- ❌ 错误：在
service/user.go里import "app/repo"并声明var userRepo = &repo.UserRepoImpl{} - ✅ 正确：定义
type UserService struct { repo contract.UserRepo }，构造时传入：svc := &UserService{repo: realRepo} - 如果用 Wire 或 Dig，确保 provider 函数不跨包 import 实现，只 import contract
这样做还能提升可测试性——单元测试时直接传入 mock 实现，不用动 import 或改包结构。
警惕嵌套 import 和 go:embed / init() 带来的隐式依赖
有时候表面没循环，但 go:embed 文件路径、init() 函数里的调用、或某个子包间接 import 了对方，也会触发循环。这类问题不会立刻暴露，而是在 build 或 test 时突然报错。
- 用
go list -f '{{.Deps}}' ./pkg/a查看 a 的所有直接/间接依赖，搜里面是否含 b - 检查所有
init()函数——它会在 import 时执行，如果里面调用了对方包的函数，就算隐式依赖 -
go:embed路径若指向另一个模块下的文件，可能触发该模块被 import，需确认路径是否跨包
真正麻烦的从来不是接口怎么写，而是那些藏在 init、embed 或 vendor 里的间接引用——它们会让循环依赖在重构后某天突然冒出来。
