1. Go 项目结构演进：从单体到分层再到依赖注入的架构演变

在 Go 语言工程实践中，项目结构的演进并非一蹴而就，而是随着业务复杂度、团队规模以及测试要求的提升逐步迭代。理解这一演进路径，是掌握依赖注入与测试闭环的基础。

1.1 第一阶段：单体结构（Monolithic Structure）

早期 Go 项目或小型工具通常采用单体结构：所有业务逻辑、数据访问、路由处理都集中在同一个包甚至同一个文件中。这种结构的核心特征是高耦合、低分离。

// 单体结构示例：所有逻辑揉在一起
package main

import (
    "database/sql"
    "encoding/json"
    "net/http"
)

func handleUser(w http.ResponseWriter, r *http.Request) {
    db, _ := sql.Open("postgres", "dsn")
    row := db.QueryRow("SELECT name FROM users WHERE id = $1", 1)
    var name string
    row.Scan(&name)
    json.NewEncoder(w).Encode(map[string]string{"name": name})
}

func main() {
    http.HandleFunc("/user", handleUser)
    http.ListenAndServe(":8080", nil)
}

1.2 第二阶段：分层架构（Layered Architecture）

随着项目增长，开发者开始按职责分层：handler（处理层）→ service（业务层）→ repository（数据层）。每一层只依赖相邻的下层，通过接口定义依赖关系。

// 分层架构示例：通过接口解耦
type UserRepository interface {
    FindByID(id int) (*User, error)
}

type UserService struct {
    repo UserRepository  // 依赖接口，而非具体实现
}

func (s *UserService) GetUser(id int) (*User, error) {
    return s.repo.FindByID(id)
}

type UserHandler struct {
    svc *UserService
}

func (h *UserHandler) HandleGetUser(w http.ResponseWriter, r *http.Request) {
    user, _ := h.svc.GetUser(1)
    json.NewEncoder(w).Encode(user)
}

1.3 第三阶段：依赖注入（Dependency Injection）

分层架构虽然解决了职责分离，但带来了新的问题：谁负责创建这些依赖？ 在分层架构中，通常由上层手动创建下层实例，导致高层仍然依赖低层的具体实现。依赖注入（DI）将依赖的创建与组装从业务代码中剥离，交由容器或启动代码统一管理。

// 依赖注入示例：通过构造函数注入
func main() {
    // 在启动阶段组装依赖
    db := connectDB()
    repo := NewPostgresUserRepository(db)
    svc := NewUserService(repo)
    handler := NewUserHandler(svc)

    http.HandleFunc("/user", handler.HandleGetUser)
    http.ListenAndServe(":8080", nil)
}

// 测试时只需替换为 mock
func TestGetUser(t *testing.T) {
    mockRepo := new(MockUserRepository)
    mockRepo.On("FindByID", 1).Return(&User{Name: "Alice"}, nil)

    svc := NewUserService(mockRepo)  // 注入 mock
    user, _ := svc.GetUser(1)
    assert.Equal(t, "Alice", user.Name)
}

1.4 演进对比总结