3. 依赖注入基础：Go中手动DI vs 依赖反转原则(IoC)的对比

在微服务工程中，依赖管理是架构质量的基石。本章从最基础的手动依赖注入（Manual DI）出发，对比依赖反转原则（DIP）与控制反转（IoC）在Go语言中的实际表现，帮助你在工程落地时做出正确的设计决策。

3.1 依赖反转原则（DIP）在Go中的体现

依赖反转原则（Dependency Inversion Principle）是SOLID原则中的“D”，其核心定义包含两层含义：

• 高层模块不应依赖低层模块：两者都应依赖抽象（接口）。
• 抽象不应依赖细节：细节应依赖抽象。

在Go语言中，DIP通过接口（interface）天然实现。Go的隐式接口实现机制使得依赖反转比Java/C#更加轻量，无需显式声明“implements”。

// 抽象层：定义接口
type UserRepository interface {
    FindByID(ctx context.Context, id string) (*User, error)
    Save(ctx context.Context, user *User) error
}

// 高层业务逻辑：依赖抽象，不依赖具体实现
type UserService struct {
    repo UserRepository  // 依赖接口
}

func (s *UserService) GetUser(ctx context.Context, id string) (*User, error) {
    return s.repo.FindByID(ctx, id)
}

// 低层具体实现：实现接口
type MySQLUserRepository struct {
    db *sql.DB
}

func (r *MySQLUserRepository) FindByID(ctx context.Context, id string) (*User, error) {
    // MySQL 具体查询逻辑
    row := r.db.QueryRowContext(ctx, "SELECT id, name FROM users WHERE id = ?", id)
    // ...
}

3.2 手动依赖注入（Manual DI）实战

手动DI是指在应用启动时，由开发者显式地创建依赖对象并注入到消费者中。在Go微服务中，这是最常用、最透明的DI方式。

3.3 手动DI vs IoC容器：核心差异

控制反转（IoC）容器（如Google Wire、Uber Dig）通过反射或代码生成自动管理依赖生命周期。下表对比手动DI与IoC容器的关键差异：

3.4 工程落地：何时选择手动DI，何时选择IoC容器

基于Go微服务的工程实践，我们总结出以下决策路径：

1. 团队规模 < 10人，服务依赖 < 20个：优先选择手动DI。代码显式、易于调试、无需引入额外依赖。
2. 团队规模 > 10人，服务依赖 > 50个：考虑使用Google Wire（编译时DI）。Wire通过代码生成避免反射开销，同时保留类型安全。
3. 需要运行时动态替换依赖（如插件系统、A/B测试）：考虑Uber Dig（运行时反射），但需注意性能损耗。
4. 单元测试覆盖率要求 > 80%：手动DI + 接口Mock是最佳组合，测试代码与生产代码解耦清晰。

3.5 依赖反转与依赖注入的协同关系

理解DIP与DI的关系是本章的关键：

• DIP是设计原则：告诉我们应该依赖抽象（接口），而不是具体实现。
• DI是实现模式：告诉我们应该如何将依赖从外部注入，而不是在内部创建。
• IoC是框架特性：将依赖管理的控制权从应用代码转移到框架或容器。

在Go微服务中，DIP + 手动DI的组合是最稳健的工程实践。它既遵循了面向接口设计的原则，又避免了IoC容器带来的隐式复杂性和调试困难。