go依赖注入不由go.mod实现，它仅管理模块版本和导入路径；真正依赖注入靠手动构造或di库在运行时完成对象创建与绑定。
Go 依赖注入不是靠 go.mod 解决的
go.mod 管理的是模块版本和构建时的导入路径，它不参与运行时对象创建或依赖绑定。把依赖注入理解成“用 go.mod 控制包依赖顺序”是常见误解——go build 会按 import 声明静态解析包，但具体哪个 struct 实例被传给另一个 struct，完全由你手写代码或借助 DI 库决定。
真正起作用的是初始化逻辑：比如在 main() 里 new 一个 DB，再把它塞进 UserService 的字段里。go.mod 只确保你 import 的 github.com/jmoiron/sqlx 能被找到，不负责“谁初始化、谁传参、谁接管生命周期”。
手动注入比引入 DI 框架更可控
Go 生态里没有像 Spring 那样内建 DI 容器，主流做法是显式构造依赖链。这不是妥协，而是契合 Go 的直觉设计：少魔法、易追踪、调试不跳转。
- 避免用
dig或wire过早抽象——它们需要额外学习语法、生成代码、处理循环依赖提示，而多数服务启动逻辑就十几行new和赋值 - 接口定义要窄：
type DBExecutor interface { QueryRow(...); Exec(...) }比直接依赖*sqlx.DB更利于 mock 和替换 - 构造函数优先用参数接收依赖，而非全局变量或 init 函数：函数签名即契约，
NewUserService(db DBExecutor, cache CacheClient)一眼看懂要什么
wire 生成代码容易掩盖初始化顺序问题
wire 把依赖图编译成普通 Go 代码，看似“零运行时开销”，但一旦出现 wire: injection failed: no provider found for *http.Client 这类错误，你得回溯整个 WireSet 链，而不是直接看哪一行 new 漏了参数。
立即学习“go语言免费学习笔记（深入）”；
更隐蔽的问题是：wire 不校验初始化时机。比如 cache.NewRedisClient() 在 wire 图里被多次调用，可能无意中新建了多个连接池；或者 DB 初始化失败后，下游 service 的构造函数仍被生成出来，导致 panic 发生在 main() 之后、业务逻辑之前，堆栈难定位。
- 只在大型 CLI 工具或微服务网关等依赖层级 >5 层时考虑
wire - 所有
wire.Build文件必须和main.go同包，否则生成代码无法访问未导出类型 - 用
wire inject命令前先跑go run .确保手动构造能跑通——别让工具替你掩盖基础逻辑缺陷
测试时绕过 DI 框架反而更轻量
单元测试不需要启动完整依赖树。与其在 test 文件里写一堆 wire.NewSet(...)，不如直接 new 一个假实现：
func TestUserService_GetUser(t *testing.T) {
svc := NewUserService(
&mockDB{rows: []user{{ID: 1, Name: "a"}}},
&mockCache{},
)
// ...
}
mock 类型不用实现全部方法，只 stub 当前测试路径用到的那几个。Go 的接口是隐式实现的，mockDB 只要满足 DBExecutor 就行，不用管它有没有 BeginTx。
真正的复杂点在于：当某个 service 同时依赖 DB 和 HTTP client，且两者都需超时控制时，你得在构造函数里传两个 context.Context 或统一用一个配置结构体封装——这种耦合不是 DI 框架能自动解的，得靠你设计接口时想清楚边界。
