Go编译器在构建阶段强制要求import依赖图为有向无环图（DAG），发现A→B→A即报“import cycle not allowed”，无法延迟加载或绕过；接口应由调用方定义，函数变量可实现弱绑定式依赖注入。
为什么 import 循环会直接报错，而不是延迟加载？
Go 编译器在构建阶段就做完整的包依赖图分析，import 关系必须是**有向无环图（DAG）**。一旦发现 A → B → A 这类路径，立刻终止并报 import cycle not allowed。这不是运行时问题，没法靠 init 顺序或接口绕过去——编译不过就是过不了。
常见错误现象：import cycle not allowed in test、某个包明明只在测试文件里引用却也触发循环、重构时加了个新 import 突然全项目编译失败。
- 检查所有
import语句，包括测试文件（_test.go）、内部vendor或replace引入的路径 - 用
go list -f '{{.Deps}}' pkgpath查依赖链，配合grep手动追一圈 - 临时删掉疑似“中间人”包的 import，看是否还报错——这是最快速定位哪条边成环的方法
接口定义该放在调用方还是被调用方？
谁依赖接口，谁就该定义它。把 UserService 接口放在 user 包里，然后让 order 包去 import "user"，等于把 order 的逻辑耦合进了 user 的契约里——这反而制造了反向依赖风险。
正确做法：在 order 包内定义 type UserGetter interface { GetByID(id int) (*User, error) }，再让 user 包实现它。这样 order 只 import 自己的接口，user 只 import order 的接口（注意：不是反过来）。
立即学习“go语言免费学习笔记（深入）”；
- 接口名别带包名前缀（比如别叫
UserUserService），它属于使用它的上下文 - 如果多个包都要用同一组行为，抽成独立的
contract或port包，但这个包不能 import 任何业务包 - 避免在接口里塞太多方法，否则实现方被迫依赖一堆不相关的包
如何用 init() 或函数变量打破 import 链？
init() 不解决循环 import，但它能帮你把“强依赖”转成“弱绑定”。比如 payment 包需要调用 notify 包发消息，但又不想 import 它（怕形成 payment → notify → order → payment）。
做法是：在 payment 包里声明一个可变的函数变量，启动时由主程序注入具体实现：
var SendNotification func(ctx context.Context, msg string) error
func ProcessPayment(...) error {
// ...
if SendNotification != nil {
SendNotification(ctx, "paid")
}
return nil
}
主程序（main.go）里 import 所有包后，再赋值：
payment.SendNotification = notify.SendEmail
- 这种模式本质是手动实现依赖注入，适合小规模解耦
- 别在
init()里调用其他包的函数——那只是把 import 错误推迟到初始化阶段，依然会触发循环检测 - 函数变量类型要定义在调用方包内，不能从被调用方 import 过来
什么时候该拆包，什么时候该合并？
拆包不是为“高内聚低耦合”而拆，是为**明确依赖方向和发布节奏**。一个 model 包被 5 个业务包 import，但它只含结构体和 JSON 标签？没问题。但如果它开始 import database/sql 或调用 http.Client，说明它已经越界了。
容易踩的坑：
- 把所有“工具函数”塞进
util包，结果util反而成了循环中心——因为它 import 了太多业务包来复用逻辑 - 按功能拆（如
auth、billing）但没隔离数据访问层，导致每个包都得 importdb，而db又 import 所有 model - 过度分包造成 import 路径冗长（
github.com/x/y/z/internal/infra/db），反而增加维护成本
判断依据很简单：如果两个包的修改总是同时发生、发布版本号总是一致、测试必须一起跑，那它们大概率不该分开。
