3、接口与依赖注入：Go接口作为契约，构造函数注入与函数选项模式

在Go项目中，接口是连接生产代码与测试代码的核心契约。本章将深入探讨如何利用Go接口定义稳定的边界，并通过构造函数注入与函数选项模式，构建出既灵活又可测试的软件架构。

3.1 接口作为契约：定义领域边界

Go的接口是隐式实现的，这为定义领域边界提供了极大的灵活性。一个接口代表一组方法契约，任何实现了这些方法的类型都自动满足该接口。在测试中，我们可以用模拟实现（Mock/Stub）替换真实依赖，从而隔离被测单元。

以下是一个典型的领域接口定义示例：

// 数据存储接口 —— 领域边界
type UserRepository interface {
    FindByID(ctx context.Context, id string) (*User, error)
    Save(ctx context.Context, user *User) error
}

// 通知服务接口 —— 另一个领域边界
type NotificationService interface {
    SendWelcomeEmail(ctx context.Context, user *User) error
}

接口作为契约，带来了以下测试优势：

3.2 构造函数注入：显式依赖声明

构造函数注入是最常见、最直观的依赖注入方式。通过将依赖作为参数传入构造函数，对象的依赖关系在创建时就被明确声明，且不可变。

// 业务服务 —— 依赖通过构造函数注入
type UserService struct {
    repo UserRepository
    notif NotificationService
}

// NewUserService 构造函数：显式声明所有依赖
func NewUserService(repo UserRepository, notif NotificationService) *UserService {
    return &UserService{
        repo:  repo,
        notif: notif,
    }
}

// Register 业务方法
func (s *UserService) Register(ctx context.Context, user *User) error {
    if err := s.repo.Save(ctx, user); err != nil {
        return fmt.Errorf("save user: %w", err)
    }
    if err := s.notif.SendWelcomeEmail(ctx, user); err != nil {
        // 通知失败可记录日志，但不影响主流程
        log.Printf("send welcome email failed: %v", err)
    }
    return nil
}

构造函数注入的测试示例：

func TestUserService_Register(t *testing.T) {
    // 准备Mock依赖
    mockRepo := new(MockUserRepository)
    mockNotif := new(MockNotificationService)

    // 设置期望行为
    mockRepo.On("Save", mock.Anything, mock.Anything).Return(nil)
    mockNotif.On("SendWelcomeEmail", mock.Anything, mock.Anything).Return(nil)

    // 通过构造函数注入Mock
    svc := NewUserService(mockRepo, mockNotif)

    // 执行测试
    err := svc.Register(context.Background(), &User{ID: "123", Name: "Alice"})

    // 验证结果
    assert.NoError(t, err)
    mockRepo.AssertExpectations(t)
    mockNotif.AssertExpectations(t)
}

3.3 函数选项模式：灵活配置与测试

当构造函数参数过多或需要可选配置时，函数选项模式（Functional Options Pattern）提供了优雅的解决方案。它允许在保持构造函数签名简洁的同时，提供灵活的配置能力。

// 配置选项类型
type Option func(*Config)

// 内部配置结构
type Config struct {
    Timeout    time.Duration
    RetryCount int
    Logger     *log.Logger
}

// 默认配置
func defaultConfig() *Config {
    return &Config{
        Timeout:    30 * time.Second,
        RetryCount: 3,
        Logger:     log.Default(),
    }
}

// 选项函数
func WithTimeout(d time.Duration) Option {
    return func(c *Config) {
        c.Timeout = d
    }
}

func WithRetryCount(n int) Option {
    return func(c *Config) {
        c.RetryCount = n
    }
}

func WithLogger(l *log.Logger) Option {
    return func(c *Config) {
        c.Logger = l
    }
}

// 支持选项的构造函数
func NewUserServiceWithOptions(repo UserRepository, notif NotificationService, opts ...Option) *UserService {
    cfg := defaultConfig()
    for _, opt := range opts {
        opt(cfg)
    }
    return &UserService{
        repo:    repo,
        notif:   notif,
        timeout: cfg.Timeout,
        retry:   cfg.RetryCount,
        logger:  cfg.Logger,
    }
}

函数选项模式在测试中的典型应用：

func TestUserService_WithCustomTimeout(t *testing.T) {
    mockRepo := new(MockUserRepository)
    mockNotif := new(MockNotificationService)

    // 注入自定义超时配置，用于测试超时场景
    svc := NewUserServiceWithOptions(
        mockRepo,
        mockNotif,
        WithTimeout(100*time.Millisecond),  // 测试用短超时
        WithRetryCount(1),                   // 测试用单次重试
    )

    // 模拟超时
    mockRepo.On("Save", mock.Anything, mock.Anything).Return(context.DeadlineExceeded)

    err := svc.Register(context.Background(), &User{ID: "timeout-test"})
    assert.Error(t, err)
    assert.Contains(t, err.Error(), "deadline exceeded")
}

3.4 两种模式的对比与选择

3.5 接口与依赖注入架构图

下图展示了接口作为契约、构造函数注入与函数选项模式在整体架构中的协作关系：

3.6 实践建议与常见陷阱

• 接口粒度要适中： 接口方法不宜过多（建议不超过5个），否则难以Mock。考虑按职责拆分接口（接口隔离原则）。
• 避免接口污染： 不要为每个结构体都创建接口。只在需要解耦或测试替换的地方定义接口。
• 构造函数注入优先： 对于核心依赖，始终使用构造函数注入。函数选项模式只用于可选配置。
• 避免全局状态： 不要使用全局变量或单例来获取依赖，这会破坏可测试性。
• 接口定义位置： 接口定义在消费者侧（使用方），而非生产者侧（实现方）。这符合Go的隐式实现哲学。

3.7 小结