4. 依赖注入基础：构造函数注入、setter注入、接口注入、Go中的依赖注入实践

依赖注入（Dependency Injection，DI）是微服务架构中实现控制反转的核心手段。在业务接口编排场景中，编排层需要调用多个下游服务（如用户服务、订单服务、库存服务），如果编排层直接 new 这些服务的客户端，会导致代码耦合度高、难以单元测试、无法灵活替换实现。DI 通过将依赖的创建与使用分离，让组件只声明“我需要什么”，而不关心“谁创建它”。

4.1 三种经典注入方式对比

4.2 构造函数注入：Go 中的标准实践

构造函数注入在 Go 中表现为 NewXXX 函数接受依赖作为参数，返回业务结构体。这种方式强制调用方在创建对象时提供所有必需的依赖，避免了空指针或运行时缺失依赖的风险。

// 定义依赖接口
type UserRepo interface {
    GetUser(ctx context.Context, id string) (*User, error)
}

type OrderRepo interface {
    GetOrders(ctx context.Context, userID string) ([]Order, error)
}

// 编排服务：通过构造函数注入所有依赖
type OrderOrchestrator struct {
    userRepo  UserRepo
    orderRepo OrderRepo
    cache     Cache
}

// NewOrderOrchestrator 构造函数注入 —— 依赖在构造时全部传入
func NewOrderOrchestrator(userRepo UserRepo, orderRepo OrderRepo, cache Cache) *OrderOrchestrator {
    return &OrderOrchestrator{
        userRepo:  userRepo,
        orderRepo: orderRepo,
        cache:     cache,
    }
}

// GetUserOrders 业务编排方法
func (o *OrderOrchestrator) GetUserOrders(ctx context.Context, userID string) (*UserOrders, error) {
    user, err := o.userRepo.GetUser(ctx, userID)
    if err != nil {
        return nil, fmt.Errorf("get user: %w", err)
    }
    orders, err := o.orderRepo.GetOrders(ctx, userID)
    if err != nil {
        return nil, fmt.Errorf("get orders: %w", err)
    }
    return &UserOrders{User: user, Orders: orders}, nil
}

4.3 Setter 注入：可选依赖与延迟注入

Setter 注入通过公开的 SetXXX 方法在对象构造后设置依赖。它适用于可选依赖或需要在运行时替换实现的场景。但缺点是无法在编译期保证依赖一定被设置，容易导致运行时空指针。

type FlexibleOrchestrator struct {
    primaryRepo   UserRepo   // 必需依赖，构造函数注入
    secondaryRepo UserRepo   // 可选依赖，Setter 注入
    logger        Logger
}

// 构造函数只注入必需依赖
func NewFlexibleOrchestrator(primary UserRepo, logger Logger) *FlexibleOrchestrator {
    return &FlexibleOrchestrator{
        primaryRepo: primary,
        logger:      logger,
    }
}

// SetSecondaryRepo Setter 注入可选依赖
func (f *FlexibleOrchestrator) SetSecondaryRepo(repo UserRepo) {
    f.secondaryRepo = repo
}

// GetUser 使用主仓库，如果设置了副仓库则做双写
func (f *FlexibleOrchestrator) GetUser(ctx context.Context, id string) (*User, error) {
    user, err := f.primaryRepo.GetUser(ctx, id)
    if err != nil {
        return nil, err
    }
    if f.secondaryRepo != nil {
        // 异步双写到副仓库
        go func() {
            _ = f.secondaryRepo.GetUser(ctx, id) // 实际可能是 Set 操作
        }()
    }
    return user, nil
}

4.4 接口注入：框架层面的依赖注入

接口注入要求被注入方实现一个特定的 Inject 接口，由注入方在运行时调用该接口传入依赖。这种方式在 Go 中较少直接使用，更多被 DI 框架（如 google/wire、uber/fx）在底层采用。

// 定义注入接口
type RepoInjector interface {
    InjectUserRepo(repo UserRepo)
    InjectOrderRepo(repo OrderRepo)
}

// 编排服务实现注入接口
type InjectableOrchestrator struct {
    userRepo  UserRepo
    orderRepo OrderRepo
}

func (i *InjectableOrchestrator) InjectUserRepo(repo UserRepo) {
    i.userRepo = repo
}

func (i *InjectableOrchestrator) InjectOrderRepo(repo OrderRepo) {
    i.orderRepo = repo
}

// 框架层面的注入器
type Container struct {
    userRepo  UserRepo
    orderRepo OrderRepo
}

func (c *Container) Resolve(target RepoInjector) {
    target.InjectUserRepo(c.userRepo)
    target.InjectOrderRepo(c.orderRepo)
}

4.5 Go 中的依赖注入实践：从手写到框架

在 Go 业务接口编排中，依赖注入的实践可以分为三个层次：

1. 手写 DI（小项目）：在 main.go 或 wire.go 中手动创建所有依赖并调用构造函数。
2. 代码生成 DI（中等项目）：使用 google/wire 通过声明 ProviderSet 自动生成注入代码。
3. 运行时 DI 容器（大型项目）：使用 uber/fx 或 dig 在运行时管理依赖生命周期。

// 手写 DI —— 清晰但繁琐
func main() {
    db := database.NewConnection()
    cache := redis.NewClient()
    userRepo := repository.NewUserRepo(db)
    orderRepo := repository.NewOrderRepo(db)
    svc := service.NewOrderOrchestrator(userRepo, orderRepo, cache)
    // ... 启动 HTTP 服务
}

// 使用 google/wire —— 声明式代码生成
// wire.go
// +build wireinject
func InitializeOrchestrator() *service.OrderOrchestrator {
    wire.Build(
        database.NewConnection,
        redis.NewClient,
        repository.NewUserRepo,
        repository.NewOrderRepo,
        service.NewOrderOrchestrator,
    )
    return nil
}

4.6 依赖注入在业务编排中的典型结构

下图展示了一个典型的业务编排服务如何通过构造函数注入组织依赖关系：

4.7 依赖注入与单元测试

依赖注入最大的收益体现在可测试性上。通过构造函数注入接口，测试代码可以轻松传入 mock 实现，隔离被测试单元。

// 测试代码 —— 使用 mock 进行单元测试
func TestOrderOrchestrator_GetUserOrders(t *testing.T) {
    // 创建 mock 依赖
    mockUserRepo := new(MockUserRepo)
    mockOrderRepo := new(MockOrderRepo)
    mockCache := new(MockCache)

    // 设置 mock 行为
    mockUserRepo.On("GetUser", mock.Anything, "user-1").
        Return(&User{ID: "user-1", Name: "Alice"}, nil)
    mockOrderRepo.On("GetOrders", mock.Anything, "user-1").
        Return([]Order{{ID: "order-1", Amount: 100}}, nil)

    // 通过构造函数注入 mock
    svc := NewOrderOrchestrator(mockUserRepo, mockOrderRepo, mockCache)

    // 执行测试
    result, err := svc.GetUserOrders(context.Background(), "user-1")
    assert.NoError(t, err)
    assert.Equal(t, "Alice", result.User.Name)
    assert.Len(t, result.Orders, 1)

    // 验证 mock 调用
    mockUserRepo.AssertExpectations(t)
    mockOrderRepo.AssertExpectations(t)
}

4.8 依赖注入常见陷阱与最佳实践