Go依赖注入核心是显式传递依赖、接口抽象和构造函数注入，避免反射与全局变量；通过接口定义契约，用构造函数注入具体实现，支持测试与环境切换，大规模项目可选Wire等生成式容器。
在 Go 语言中实现依赖注入（Dependency Injection, DI），核心不是靠框架“自动扫包”或“反射注入”，而是通过显式传递依赖、接口抽象和构造函数参数设计，让组件不直接创建其依赖，而是由外部提供——这天然契合 Go 的简洁哲学。
用接口定义契约，隔离具体实现
Go 没有类继承，但接口即契约。把依赖的行为抽象为接口，组件只依赖接口，不关心谁实现它。
例如，一个用户服务需要发送通知：
// 定义通知行为接口
type Notifier interface {
Send(to string, msg string) error
}
// 具体实现：邮件通知
type EmailNotifier struct{}
func (e EmailNotifier) Send(to, msg string) error {
fmt.Printf("Email to %s: %s\n", to, msg)
return nil
}
// 具体实现：短信通知（可随时替换）
type SMSNotifier struct{}
func (s SMSNotifier) Send(to, msg string) error {
fmt.Printf("SMS to %s: %s\n", to, msg)
return nil
}
这样，用户服务就不再硬编码调用 sendEmail()，而是接收一个 Notifier 接口实例。
通过构造函数注入依赖（推荐方式）
Go 中最自然、最易测试的 DI 方式是“构造函数注入”：把依赖作为结构体字段，在初始化时传入。
继续上面的例子：
type UserService struct {
notifier Notifier // 依赖接口，非具体类型
}
// 构造函数显式接收依赖
func NewUserService(n Notifier) *UserService {
return &UserService{notifier: n}
}
func (u *UserService) CreateUser(name, email string) error {
// ... 创建用户逻辑
return u.notifier.Send(email, "Welcome!")
}
- 调用方完全控制依赖实例的创建时机和类型
- 单元测试时可轻松传入 mock 实现（比如
MockNotifier） - 无运行时反射、无隐藏依赖，代码可读性高
避免全局变量和单例模式
不要用 var db *sql.DB 全局变量或 init() 初始化依赖。这会导致：
- 无法为不同环境（测试/开发/生产）切换依赖
- 难以并行测试（状态污染）
- 隐藏组件间的耦合关系
正确做法：把数据库连接、缓存客户端等也作为依赖传入。例如：
type UserRepository struct {
db *sql.DB
}
func NewUserRepository(db *sql.DB) *UserRepository {
return &UserRepository{db: db}
}
type UserService struct {
repo *UserRepository
notifier Notifier
}
func NewUserService(repo *UserRepository, n Notifier) *UserService {
return &UserService{repo: repo, notifier: n}
}
可选：使用依赖注入容器（仅当规模较大时）
小项目无需容器；中大型项目若依赖层级深、初始化逻辑复杂，可引入轻量容器如 Uber FX 或 Google Wire。
Wire 是代码生成型 DI 工具，编译期解析依赖图，生成构造代码，零反射、零运行时开销：
- 你写
inject.go声明提供者函数（如func newDB() *sql.DB） - 运行
wire generate自动生成newApp()函数 - 最终仍是一堆显式构造调用，只是帮你写好了
它不改变 DI 本质，只是提升可维护性，不是必须项。
