Go模块管理不负责依赖注入，DI需额外工具如Wire实现；Wire在编译期生成无反射的初始化代码，避免运行时错误与IDE功能退化，但Provider签名变更会导致构建失败且不受go.mod版本约束保护。
Go 模块管理不负责依赖注入
Go 的 go mod 只管包的版本下载、路径解析和构建时的 import 路径映射，它完全不参与运行时对象的创建、生命周期管理或依赖组装。依赖注入（DI）是应用层设计问题，需要额外工具或手写代码实现。
常见误解是认为 go.mod 文件里写了 github.com/google/wire 就等于“启用了 DI”——其实那只是把 Wire 工具加进了依赖，真正生成构造函数还得执行 go run wire.go。
Wire 是目前最主流的编译期 DI 方案
Wire 通过分析 Go 源码中的函数签名和结构体字段，在编译前生成硬编码的初始化代码，不引入反射或运行时解析开销。
-
injector.go中定义func InitializeServer() (*Server, error)，标注//+build wireinject - 对应
wire.go里调用wire.Build(...)列出所有提供者（Provider）函数 - 运行
go generate或go run github.com/google/wire/cmd/wire后，生成wire_gen.go - 生成的代码里全是普通 Go 调用，可直接 debug、可被 IDE 跳转
func initializeServer() (*Server, error) {
db := newDB()
cache := newCache()
handler := newHandler(db, cache)
server := &Server{Handler: handler}
return server, nil
}
为什么不用基于反射的 DI 框架？
Go 社区普遍回避运行时 DI 框架（如类似 Spring 的容器），核心原因很实际：
立即学习“go语言免费学习笔记（深入）”；
- 反射无法静态检查依赖是否满足，错误拖到运行时才暴露
- IDE 失去跳转和重命名支持，
ctrl+click进不去构造逻辑 - 二进制体积增大（即使不用反射，某些框架仍带大量未使用代码）
- Wire 生成的代码和手写初始化几乎无差别，只是省去了重复粘贴
比如把 newDB() 改成 NewDBWithTimeout(...)，Wire 会立刻报错“no provider found”，而反射方案可能直到启动连不上数据库才失败。
模块版本与 DI 绑定的隐性风险
DI 的 Provider 函数签名一旦变更，就可能破坏 Wire 构建——但这种破坏不会体现在 go.mod 版本约束里。
- 假设
v1.2.0的github.com/example/repo提供了func NewClient() *Client - 升级到
v1.3.0后该函数变成func NewClient(cfg Config) (*Client, error) -
go mod tidy仍能成功，但wire build直接失败：“cannot use NewClient as type func() *Client” - 这类兼容性断裂必须靠 Provider 接口抽象、语义化版本控制或集成测试覆盖
真正容易被忽略的是：模块版本号管不住接口契约，而 DI 的脆弱点恰恰就在函数签名这一层。
