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: %sn", to, msg) return nil } // 具体实现：短信通知（可随时替换） type SMSNotifier struct{} func (s SMSNotifier) Send(to, msg string) error { fmt.Printf("SMS to %s: %sn", to, msg) return nil }
这样，用户服务就不再硬编码调用 sendEmail()，而是接收一个 Notifier 接口实例。
立即学习“go语言免费学习笔记（深入）”；
通过构造函数注入依赖（推荐方式）
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 工具，编译期解析依赖图，生成构造代码，零反射、零运行时开销：
它不改变 DI 本质，只是提升可维护性，不是必须项。