最常见源头是用包路径直接import互相依赖的包，正确做法是提取接口到独立包并注入实现。Go编译期禁止import循环，必须通过接口解耦、职责分离和依赖注入重构破除，internal包仅限模块内访问，不可滥用为私有区。
用接口定义契约，而不是包路径
直接 import 两个互相需要的包，是循环依赖最常见源头。Go 不会报编译错误，但 go build 会在解析依赖图时卡住，或导致 import cycle not allowed 错误（尤其在 internal 包中更敏感）。
正确做法是：把双方交互的「能力」抽成接口，放在一个**不依赖任何一方的独立包里**（比如 pkg/domain 或 internal/contract），然后让 A 和 B 分别 import 这个接口包，再通过构造函数或 DI 容器注入具体实现。
- 接口包不能 import A 或 B 的任何具体类型，否则又引入新依赖
- 业务包 A 实现接口时，只 import 接口包 + 自己需要的底层工具（如
database/sql），不 import B - 调用方 B 持有接口类型字段（如
repo UserRepository），而非*mysql.UserRepo
避免在 internal 中暴露具体实现类型
internal 目录本意是限制外部访问，但很多人误把它当“随便放”的私有区，结果把数据库 model、HTTP handler、gRPC service 全塞进去，反而加剧耦合。
真正该放 internal 的只有：业务逻辑核心（internal/order）、跨域共享的领域模型（internal/domain）、以及明确不对外暴露的基础设施封装（如 internal/db）。所有向外提供能力的入口，必须通过接口暴露。
立即学习“go语言免费学习笔记（深入）”；
- 如果
internal/order/service.go返回*order.Order，而internal/payment又要 import 它——立刻打破边界 - 改成返回
order.Orderer接口，且该接口定义在pkg/order（非 internal） -
internal/order可以实现它，internal/payment只需依赖pkg/order，不碰internal/order
用 go mod graph 主动识别隐性依赖链
模块间依赖不是写在 import 里的才叫依赖。比如 A 调用 B 的函数，B 的函数参数类型来自 C 包——A 就间接依赖 C。这种隐性依赖在重构时极易遗漏，导致 go mod tidy 突然拉入不该有的包，或测试失败。
运行 go mod graph | grep your-module-name 能看到当前模块直接/间接依赖的所有包及其版本。重点关注那些没在代码里显式 import、却出现在图中的第三方包。
- 出现
your/project/internal/a@v0.0.0→github.com/some/thing@v1.2.3？说明 a 包里用了它，但没声明 require —— 运行go mod tidy会自动补上 - 发现
your/project/pkg/x→your/project/internal/y→your/project/pkg/z？说明 x 间接依赖 z，可能违反分层原则 - 某包被多个子模块重复 require 不同版本？用
go list -m all | grep package-name查清来源
DI 容器不是银弹，优先手工注入简单场景
像 dig 或 fx 这类容器确实能自动解构依赖树，但在大型项目里，过度依赖反射会带来三个实际问题：启动慢（尤其带大量 provider）、调试困难（错误堆栈指向容器内部而非你的代码）、以及隐藏了真实的初始化顺序。
建议只对「生命周期复杂」或「实现频繁切换」的组件用容器（如 logger、config、tracer），其余一律手工构造：
- main 函数里按顺序 new 依赖：先
cfg := loadConfig()，再db := NewDB(cfg)，最后svc := NewOrderService(db, cache) - 每个构造函数只接收它**直接需要**的依赖，不传 container 或 config 全局对象
- 测试时直接 new mock 实现传入，不用启动整个容器
真正难处理的是跨服务边界的依赖（比如订单服务要调支付网关），这时候才值得引入 dig 配合 interface + option 注册，而不是一上来就全盘托管。
