golang

Google Wire 依赖注入框架实战：从手动装配到代码生成的工程化实践

深入讲解 Google Wire 依赖注入框架的原理与实战，覆盖 Provider/Injector 模式、代码生成机制与大型项目中的 DI 最佳实践

Leeting Yan 2026-08-13 15 分钟阅读 7413 字

为什么需要依赖注入：手动构造的问题

在软件工程中，依赖注入（Dependency Injection，DI）是一种将对象的依赖关系从对象内部提取到外部统一管理的模式。在 Go 语言中，如果不使用依赖注入框架，开发者通常需要手动在 main 函数或初始化模块中按顺序创建和装配所有对象。这种手动构造方式在小型项目中尚可接受，但随着项目规模扩大，问题会迅速暴露。

手动构造的第一个问题是初始化顺序的耦合。当服务 A 依赖服务 B、服务 B 依赖配置 C、配置 C 又依赖环境变量解析器 D 时，开发者必须在 main 函数中精确维护这种创建顺序。一旦依赖关系发生变化——例如新增了一个中间层或某个依赖被替换为另一个实现——main 函数中的初始化代码就需要大面积修改。这种修改不仅繁琐，而且极易引入 bug（如忘记初始化某个依赖、错误的初始化顺序导致空指针）。

第二个问题是实现替换的困难。在单元测试中，我们通常需要使用 mock 实现来替代真实的依赖。手动构造时，这意味着需要为每个测试场景编写独立的初始化代码。当应用有数十个服务时，测试文件的初始化代码量可能超过测试逻辑本身。更糟糕的是，如果生产代码中的依赖关系发生了微小变化，所有相关的测试初始化代码都必须同步更新。

第三个问题是生命周期管理的混乱。数据库连接、HTTP 客户端、消息队列消费者等资源需要在应用退出时优雅关闭。手动构造时，如何确保每个资源都被正确关闭、如何处理关闭时的错误、如何控制关闭顺序，都成为 main 函数中的复杂逻辑。当应用规模扩大时，这部分代码会变得越来越难以维护。

依赖注入正是为了解决这些问题而生。它将对象的创建和依赖关系的维护从业务代码中分离出来，由框架或专门的模块统一管理。Go 社区中流行的 DI 框架主要有三大类：基于反射的运行时 DI（如 Uber 的 Dig 和 FX）、基于代码生成的编译时 DI（如 Google Wire）、以及基于结构体标签的方案。Google Wire 选择了编译时代码生成的路线，虽然使用上比运行时 DI 多了代码生成步骤，但在性能和类型安全上具有明显优势。

DI 核心概念：Provider、Injector、Binding

理解 Wire 的核心抽象是正确使用它的前提。Wire 的世界观中有三个核心概念：Provider、Injector 和 Binding。

Provider 是一个函数，负责创建某种类型的实例。在 Wire 中，任何构造函数都可以作为 Provider——只要它返回一个特定类型并可能需要若干依赖作为输入参数。例如在 func NewUserService(repo UserRepository, logger *zap.Logger) *UserService 中，这个函数就是一个提供 *UserService 的 Provider，它的输入签名表明它依赖于 UserRepository 和 *zap.Logger。Provider 也可以是返回多个值的函数，比如 func NewDB(cfg DatabaseConfig) (*sql.DB, error) 同时返回数据库连接和可能的错误。

Injector 是一组 Provider 的编排结果。它定义了如何从一组 Provider 出发，构建出最终需要的依赖图。在 Wire 中，Injector 不是手写代码，而是通过 wire.Build 声明式生成的。开发者创建一个函数，用 wire.Build(...) 声明需要哪些 Provider，然后运行 wire 命令生成该函数的实际实现。生成的实现会根据 Provider 的签名自动推导依赖关系，按正确的顺序调用 Provider 函数，形成完整的初始化链。Injector 函数通常命名为 InitializeXxx 或 wireApp，其作用是在应用启动时将所有依赖装配完毕。

Binding 是 Wire 中解决接口到实现映射的机制。当某个 Provider 需要接口类型作为参数时，Wire 需要知道哪个具体的 Provider 提供了该接口的实现。Binding 通过 wire.Bind(new(InterfaceType), new(*ConcreteType)) 来声明这种映射关系。例如 wire.Bind(new(UserRepository), new(*PostgresUserRepository)) 告诉 Wire：当需要 UserRepository 接口时，使用 *PostgresUserRepository 作为实现。Binding 是 Wire 解决 Go 接口多态性的核心工具，它完全在编译时解析，没有任何运行时开销。

Wire 的安装与代码生成机制

Wire 工具本身是一个命令行工具，通过 go install 安装。由于 Wire 采用代码生成模式，实际运行时不依赖任何额外的库——所有注入逻辑都在代码生成阶段完成，生成的代码是纯 Go，可以被任何标准工具链编译运行。这是 Wire 与运行时 DI 框架在工程模型上的根本区别。

安装命令如下：

go install github.com/google/wire/cmd/wire@latest

安装完成后，wire 命令将出现在 GOPATH/bin 或 GOBIN 目录下。Wire 的核心工作流程是：开发者在代码中编写包含 wire.Build 的 injector 函数，然后运行 wire 命令，Wire 分析这些函数并生成对应的初始化代码。生成的文件通常为 wire_gen.go，开发者将其纳入版本控制并在构建时直接使用，无需再运行 Wire。

代码生成的具体过程如下：Wire 扫描当前包中所有标记了 //go:build wireinject 的文件，解析其中的 wire.Build 调用。wire.Build 接收一组 Provider 和 Binding 声明，Wire 将这些声明构建为一个有向无环图（DAG），其中节点是类型，边是依赖关系。然后，Wire 从目标类型（即 injector 函数的返回类型）出发，反向遍历 DAG，找出从可用 Provider 到目标类型的所有路径。如果存在多条路径到达同一个类型（歧义），Wire 会报错要求开发者消除歧义。如果没有路径能到达目标类型（缺失依赖），Wire 同样会报错。

当 Wire 成功找到一条依赖路径后，它会按照图中的拓扑序生成初始化代码——先初始化最底层的依赖（如配置和环境），然后是中间层服务，最后是顶层对象。生成的代码看起来像手写代码，按顺序声明变量并调用 Provider 函数。由于这是纯代码生成，不存在反射，因此 Wire 注入的对象初始化性能与手写的完全相同。

基础 Provider 定义与 wire.Build

Wire 的使用从定义 Provider 开始。Provider 就是 Go 中的普通构造函数，无需特殊标记或标签。以下是一个最简单的 Wire 使用示例。

// provider.go
package myapp

import (
	"database/sql"
	"log"

	_ "github.com/lib/pq"
	"go.uber.org/zap"
)

// DatabaseConfig 保存数据库连接配置
type DatabaseConfig struct {
	DSN string
}

// NewDatabaseConfig 提供数据库配置
func NewDatabaseConfig() DatabaseConfig {
	return DatabaseConfig{DSN: "postgres://localhost/mydb"}
}

// NewDB 根据配置创建数据库连接
func NewDB(cfg DatabaseConfig) (*sql.DB, error) {
	db, err := sql.Open("postgres", cfg.DSN)
	if err != nil {
		return nil, err
	}
	return db, db.Ping()
}

// NewLogger 提供 zap 日志实例
func NewLogger() *zap.Logger {
	logger, err := zap.NewProduction()
	if err != nil {
		log.Fatal(err)
	}
	return logger
}

// UserService 用户服务
type UserService struct {
	DB     *sql.DB
	Logger *zap.Logger
}

// NewUserService 是 UserService 的 Provider
func NewUserService(db *sql.DB, logger *zap.Logger) *UserService {
	return &UserService{DB: db, Logger: logger}
}

// wire.go
//go:build wireinject

package myapp

import "github.com/google/wire"

// InitializeApp 是由 wire 生成的 injector
func InitializeApp() (*UserService, error) {
	wire.Build(
		NewDatabaseConfig,
		NewDB,
		NewLogger,
		NewUserService,
	)
	return nil, nil
}

# 在项目目录中运行 wire
wire ./...

上面的核心在于 wire.go 文件。文件最上方的 //go:build wireinject 构建标签表明这个文件只在 Wire 代码生成时使用，不会被编译到最终应用。InitializeApp 函数的签名声明了最终要构造的类型 *UserService，wire.Build 中列出了所有可用的 Provider。Wire 会分析这些 Provider 的签名：

NewDatabaseConfig 不需要输入，提供 DatabaseConfig
NewDB 需要 DatabaseConfig，提供 *sql.DB 和 error
NewLogger 不需要输入，提供 *zap.Logger
NewUserService 需要 *sql.DB 和 *zap.Logger，提供 *UserService

因此从 *UserService 出发可以构建出完整的依赖链，Wire 将生成按正确顺序调用这些构造函数并处理 error 的代码。生成的 wire_gen.go 中 InitializeApp 的实现类似于手写代码。

接口绑定与接口类型注入

在真实项目中，服务通常依赖接口而不是具体类型，这便于测试时替换为 mock 实现。Wire 通过 wire.Bind 解决接口到实现的映射。

// repository.go
package myapp

import "context"

// UserRepository 定义了用户仓库接口
type UserRepository interface {
	GetByID(ctx context.Context, id int) (*User, error)
	Create(ctx context.Context, user *User) error
}

type User struct {
	ID   int
	Name string
}

// PostgresUserRepository 是 UserRepository 的 PostgreSQL 实现
type PostgresUserRepository struct {
	DB *sql.DB
}

func NewPostgresUserRepository(db *sql.DB) *PostgresUserRepository {
	return &PostgresUserRepository{DB: db}
}

func (r *PostgresUserRepository) GetByID(ctx context.Context, id int) (*User, error) {
	// 实现略
	return &User{ID: id, Name: "test"}, nil
}

func (r *PostgresUserRepository) Create(ctx context.Context, user *User) error {
	// 实现略
	return nil
}

// service.go（使用接口依赖）
package myapp

type UserService struct {
	Repo   UserRepository
	Logger *zap.Logger
}

func NewUserService(repo UserRepository, logger *zap.Logger) *UserService {
	return &UserService{Repo: repo, Logger: logger}
}

// wire.go（带 binding 的 injector）
//go:build wireinject

package myapp

import "github.com/google/wire"

func InitializeApp() (*UserService, error) {
	wire.Build(
		NewDatabaseConfig,
		NewDB,
		NewLogger,
		NewPostgresUserRepository,
		wire.Bind(new(UserRepository), new(*PostgresUserRepository)),
		NewUserService,
	)
	return nil, nil
}

在这个例子中，NewUserService 需要 UserRepository 接口，但可用的 Provider 只有 NewPostgresUserRepository，它返回的是 *PostgresUserRepository 具体类型。wire.Bind(new(UserRepository), new(*PostgresUserRepository)) 建立了从接口到生成的映射。Wire 在生成代码时会 insert 一个将 *PostgresUserRepository 赋值给 UserRepository 接口变量的步骤，然后将其传入 NewUserService。

wire.Bind 本质上是一个编译时的适配器声明，它不产生任何运行时代码（接口赋值在 Go 中只是类型系统检查），因此性能损失为零。在实际工程中，通常将同一领域的接口和实现放在同一个 Provider Set 中，以模块化的方式管理绑定。

Provider Set 的组织与模块化

当项目有数十个 Provider 时，直接在 wire.Build 中列出所有函数会变得冗长且难以维护。Wire 提供了 Provider Set 机制，允许将一组 Provider 和 Binding 打包为一个命名集合，然后在 injector 中引用这个集合。

// wire.go
package myapp

import "github.com/google/wire"

// DatabaseSet 是数据层相关的 Provider 集合
var DatabaseSet = wire.NewSet(
	NewDatabaseConfig,
	NewDB,
)

// RepositorySet 是仓库层相关的 Provider 集合
var RepositorySet = wire.NewSet(
	NewPostgresUserRepository,
	wire.Bind(new(UserRepository), new(*PostgresUserRepository)),
)

// ServiceSet 是服务层相关的 Provider 集合
var ServiceSet = wire.NewSet(
	NewUserService,
)

// LoggerSet 是日志相关的 Provider 集合
var LoggerSet = wire.NewSet(
	NewLogger,
)

// wire.go（injector 文件）
//go:build wireinject

package myapp

func InitializeApp() (*UserService, error) {
	wire.Build(
		DatabaseSet,
		RepositorySet,
		ServiceSet,
		LoggerSet,
	)
	return nil, nil
}

Provider Set 的妙用不仅在于简化 injector 的声明，更在于它天然支持模块化和分层架构。在大型项目中，通常按分层或按领域模块组织 Provider Set。例如数据访问模块暴露 RepositorySet，业务逻辑模块暴露 ServiceSet，基础设施模块暴露 LoggerSet 和 ConfigSet。各模块内部可以独立维护其 Provider，只要保持 Set 的公共接口不变，内部重构不会影响其他模块的 injector。

Provider Set 还可以嵌套：一个 Set 中可以包含另一个 Set。这种组合能力使得复杂应用的依赖图可以被分解为多个层次清晰的子图。

// ApplicationSet 组合所有其他 Set
var ApplicationSet = wire.NewSet(
	DatabaseSet,
	RepositorySet,
	ServiceSet,
	LoggerSet,
)

Value Provider 与 Config 注入

在 Provider 函数中，有些依赖不需要通过构造函数创建，而是可以直接从外部传入的值。Wire 的 wire.Value 用于将这些外部值注入到依赖图中。这对于配置注入特别有用——配置文件解析出的值可以直接作为 Provider 使用。

package myapp

import "github.com/google/wire"

type ServerConfig struct {
	Port int
	Host string
}

type AppConfig struct {
	Server   ServerConfig
	Database DatabaseConfig
}

// ProvideAppConfig 从环境或文件加载配置
func ProvideAppConfig() AppConfig {
	return AppConfig{
		Server: ServerConfig{Port: 8080, Host: "0.0.0.0"},
		Database: DatabaseConfig{DSN: "postgres://localhost/mydb"},
	}
}

// ConfigSet 使用 wire.Value 注入配置
var ConfigSet = wire.NewSet(
	ProvideAppConfig,
	wire.FieldsOf(new(AppConfig), "Server"),
	wire.FieldsOf(new(AppConfig), "Database"),
)

wire.FieldsOf 是 Wire 提供的一个便利工具，它从一个结构体类型的 Provider 中提取出特定字段作为独立的 Provider。在上面的例子中，FieldsOf(new(AppConfig), "Server") 会生成一个提供 ServerConfig 的隐式 Provider，同理 DatabaseConfig 也可以从 AppConfig 中提取。这样各个层的构造函数只需要接收它们真正关心的配置子集，而无需引入整个 AppConfig。

type HTTPServer struct {
	Port int
	Svc  *UserService
}

func NewHTTPServer(cfg ServerConfig, svc *UserService) *HTTPServer {
	return &HTTPServer{Port: cfg.Port, Svc: svc}
}

Cleanup 函数与资源释放

真实的应用不仅有初始化逻辑，还有优雅关闭逻辑。数据库连接需要 Close()，HTTP 服务器需要 Shutdown()，消息队列消费者需要 Stop()。Wire 支持返回 cleanup 函数的 Provider 模式。

当一个 Provider 返回 (T, func(), error) 或 (T, func() error) 时，Wire 会识别其中的 cleanup 函数，并在生成的 injector 代码中将其收集起来。最终 injector 函数也会返回一个总的 cleanup 函数，调用它会按相反顺序执行所有 cleanup。

package myapp

import (
	"database/sql"
	"fmt"
	"net/http"
)

// NewDBWithCleanup 返回带 cleanup 的数据库连接
func NewDBWithCleanup(cfg DatabaseConfig) (*sql.DB, func(), error) {
	db, err := sql.Open("postgres", cfg.DSN)
	if err != nil {
		return nil, nil, err
	}
	cleanup := func() {
		fmt.Println("closing database connection")
		db.Close()
	}
	return db, cleanup, db.Ping()
}

// NewHTTPServerWithCleanup 返回带 shutdown 的 HTTP 服务器
func NewHTTPServerWithCleanup(cfg ServerConfig, svc *UserService) (*http.Server, func(), error) {
	mux := http.NewServeMux()
	mux.HandleFunc("/users", func(w http.ResponseWriter, r *http.Request) {
		// 处理逻辑
	})
	server := &http.Server{Addr: fmt.Sprintf("%s:%d", cfg.Host, cfg.Port), Handler: mux}
	cleanup := func() {
		fmt.Println("shutting down HTTP server")
		server.Close()
	}
	go server.ListenAndServe()
	return server, cleanup, nil
}

//go:build wireinject

package myapp

func InitializeAppWithCleanup() (*http.Server, func(), error) {
	wire.Build(
		ProvideAppConfig,
		wire.FieldsOf(new(AppConfig), "Server"),
		wire.FieldsOf(new(AppConfig), "Database"),
		NewDBWithCleanup,
		NewLogger,
		NewPostgresUserRepository,
		wire.Bind(new(UserRepository), new(*PostgresUserRepository)),
		NewUserService,
		NewHTTPServerWithCleanup,
	)
	return nil, nil, nil
}

生成的 InitializeAppWithCleanup 会返回一个聚合的 cleanup 函数，该函数会按照与初始化相反的顺序调用每个 Provider 的 cleanup。这确保了 HTTP 服务器先 shutdown，然后数据库连接再关闭，符合资源关闭的典型顺序要求。使用 cleanup 模式，开发者可以在 main 函数中通过 defer cleanup() 实现应用退出时的优雅关闭。

错误处理：Build 失败分析与调试

Wire 的错误信息通常比较直接，但在复杂项目中仍然可能遇到难以理解的报错。以下是常见错误类型和解决方案。

no provider found for X：这意味着依赖图中缺少能提供类型 X 的 Provider。解决方法是确认是否有某个 Provider 返回 X，如果没有则需要写一个；或者检查是否有依赖被遗漏。使用 wire.NewSet 组织 Provider 时，容易忘记将新写的 Provider 加入某个 Set。

multiple bindings for X：这表示有多个 Provider 都能提供类型 X，Wire 不知道用哪个。解决方法是用 wire.Bind 显式指定接口的映射实现，或者使用命名类型（如定义 type MyDB *sql.DB 来区分不同数据库连接）。

cycle detected：依赖图中存在循环依赖，例如 A 依赖 B 而 B 又依赖 A。Wire 要求依赖图必须是有向无环图。解决循环依赖通常需要重构，引入接口抽象打破循环，或使用初始化后设置（setter injection）模式。

wireinject build tag missing：injector 文件缺少 //go:build wireinject 导致 Wire 无法识别该文件。

调试技巧：在运行 wire 命令时添加 -verbose 标志可以查看详细的依赖图解析过程。对于极其复杂的项目，可以先注释掉部分 Provider，逐步缩小问题范围。保持 Provider 签名简单明确——每个 Provider 只做一件事，返回一个主要类型——是避免 Wire 混淆的最佳实践。

与 Dig/FX 的对比：编译时 vs 运行时 DI

Go 社区有两个主要的运行时 DI 框架：Uber 的 Dig 和 FX。理解它们的差异有助于为项目选择合适的方案。

Dig 基于反射实现依赖注入。开发者在 main 函数中调用 container.Provide(NewXxx) 注册 Provider，然后调用 container.Invoke 触发解析。Dig 在运行时通过反射分析函数的参数和返回值来构建依赖图。优点是无需代码生成步骤、支持更动态的场景；缺点是反射带来的运行时开销、运行时才发现依赖缺失的错误、以及反射对代码可阅读性的破坏。

FX 是在 Dig 基础上的高层封装，提供了模块化的生命周期管理和更友好的 API。FX 用 fx.Provide(NewXxx) 和 fx.Invoke 来组织依赖，并通过 fx.New 创建应用。FX 的目标是提供接近 Spring Boot 的体验，自动管理启动顺序和优雅关闭。但它同样依赖反射，且在复杂依赖图下的性能不如 Wire。

Wire 的核心优势在于零运行时开销。所有注入逻辑在编译前就已经通过代码生成完成，运行时完全是普通的 Go 函数调用。Wire 在编译期就能发现依赖缺失和循环依赖，而不是等到运行时 panic。对于性能敏感的应用和不愿引入反射依赖的项目，Wire 是更优的选择。Wire 的缺点是代码生成步骤增加了构建流程的复杂度（需要在 CI 中运行 wire 或确保 wire_gen.go 与源代码同步）。

大型项目中的 Wire 组织架构

在大型微服务或单体应用中，Wire 的组织方式直接影响项目的可维护性。以下是经过实践验证的目录结构和 Provider 组织方式。

cmd/
  server/
    main.go              # 调用 wire.InitializeApp()
    wire.go              # injector 定义
    wire_gen.go          # wire 生成的代码
internal/
  config/
    config.go            # 配置结构体和加载逻辑
  database/
    database.go          # DB Provider Set
  repository/
    repository.go        # Repository Provider Set
  service/
    service.go           # Service Provider Set
  transport/
    http/
      http.go            # HTTP server Provider Set
    grpc/
      grpc.go            # gRPC server Provider Set
wire/
  wire.go                # 全局 Provider Set 组合

每个模块目录下的 wire.go（不带 wireinject tag）定义该模块的 Provider Set：

// internal/database/wire.go
package database

import "github.com/google/wire"

var ProviderSet = wire.NewSet(
	NewConfig,
	NewDB,
)

顶层 wire/wire.go 只负责组合：

// wire/wire.go
package wire

import (
	"github.com/google/wire"
	"myapp/internal/config"
	"myapp/internal/database"
	"myapp/internal/repository"
	"myapp/internal/service"
	"myapp/internal/transport/http"
)

var AppSet = wire.NewSet(
	config.ProviderSet,
	database.ProviderSet,
	repository.ProviderSet,
	service.ProviderSet,
	http.ProviderSet,
)

这种分层组织使得每个模块独立管理自己的 Provider，模块间的依赖通过 Set 的组合体现而非直接引用彼此的 Provider 函数。

与 Clean Architecture 的结合

Clean Architecture（清晰架构）强调业务逻辑不依赖外部框架和基础设施。Wire 作为依赖注入工具，与 Clean Architecture 天然契合。在 Clean Architecture 的分层模型中：

Entities 层：核心领域模型，无外部依赖，通常不需要 DI。
Use Cases 层：业务逻辑，依赖接口（如 Repository 接口）。Wire 的 wire.Bind 在这一层设定了接口到实现的映射。
Interface Adapters 层：控制器、 presenters、网关实现。这一层提供具体的 Repository 实现、HTTP handlers、数据库接入等 Provider。
Frameworks & Drivers 层：最外层的基础设施，如 Web 框架、数据库驱动、消息队列客户端。这一层提供最基础的 Provider，如 *sql.DB、*zap.Logger。

Wire 的依赖图恰好从外向内逐层构建，与 Clean Architecture 的依赖方向一致（内层依赖外层接口，外层提供接口实现）。使用 Wire 时不需要在内层代码中引入任何 Wire 相关的 import，所有 Wire 的声明都集中在最外层的 cmd 和 wire 包中，确保了 Clean Architecture 的依赖规则不被违反。

完整实战：构建一个带 Wire 的 REST API 项目

以下是一个完整的 REST API 项目示例，展示了从数据库连接、仓库、服务到 HTTP 服务器的完整依赖注入链。

// cmd/server/main.go
package main

import (
	"fmt"
	"log"
	"os"
	"os/signal"
	"syscall"

	"myapp/internal/app"
)

func main() {
	server, cleanup, err := app.InitializeServer()
	if err != nil {
		log.Fatal(err)
	}
	defer cleanup()

	fmt.Printf("Server running on %s\n", server.Addr)

	quit := make(chan os.Signal, 1)
	signal.Notify(quit, syscall.SIGINT, syscall.SIGTERM)
	<-quit
	fmt.Println("Shutting down...")
}

// internal/config/config.go
package config

import "github.com/google/wire"

type Config struct {
	Database DatabaseConfig
	Server   ServerConfig
}

type DatabaseConfig struct {
	DSN string
}

type ServerConfig struct {
	Port int
}

func Load() Config {
	return Config{
		Database: DatabaseConfig{DSN: "postgres://localhost:5432/app"},
		Server:   ServerConfig{Port: 8080},
	}
}

var ProviderSet = wire.NewSet(
	Load,
	wire.FieldsOf(new(Config), "Database"),
	wire.FieldsOf(new(Config), "Server"),
)

// internal/database/db.go
package database

import (
	"database/sql"
	"fmt"

	"github.com/google/wire"
	_ "github.com/lib/pq"
	"myapp/internal/config"
)

func NewDB(cfg config.DatabaseConfig) (*sql.DB, func(), error) {
	db, err := sql.Open("postgres", cfg.DSN)
	if err != nil {
		return nil, nil, err
	}
	cleanup := func() {
		fmt.Println("Closing database connection")
		db.Close()
	}
	return db, cleanup, db.Ping()
}

var ProviderSet = wire.NewSet(NewDB)

// internal/repository/user.go
package repository

import (
	"context"
	"database/sql"

	"github.com/google/wire"
)

type User struct {
	ID   int
	Name string
}

// UserRepo 是用户仓库接口
type UserRepo interface {
	GetByID(ctx context.Context, id int) (*User, error)
}

type userRepo struct {
	db *sql.DB
}

func NewUserRepo(db *sql.DB) *userRepo {
	return &userRepo{db: db}
}

func (r *userRepo) GetByID(ctx context.Context, id int) (*User, error) {
	row := r.db.QueryRowContext(ctx, "SELECT id, name FROM users WHERE id=$1", id)
	user := &User{}
	err := row.Scan(&user.ID, &user.Name)
	return user, err
}

var ProviderSet = wire.NewSet(
	NewUserRepo,
	wire.Bind(new(UserRepo), new(*userRepo)),
)

// internal/service/user.go
package service

import (
	"context"

	"github.com/google/wire"
	"myapp/internal/repository"
)

type UserService struct {
	repo repository.UserRepo
}

func NewUserService(repo repository.UserRepo) *UserService {
	return &UserService{repo: repo}
}

func (s *UserService) GetUser(ctx context.Context, id int) (*repository.User, error) {
	return s.repo.GetByID(ctx, id)
}

var ProviderSet = wire.NewSet(NewUserService)

// internal/transport/http/server.go
package http

import (
	"encoding/json"
	"fmt"
	"net/http"

	"github.com/google/wire"
	"myapp/internal/config"
	"myapp/internal/service"
)

type Server struct {
	Mux *http.ServeMux
}

func NewServer(cfg config.ServerConfig, userSvc *service.UserService) (*http.Server, error) {
	mux := http.NewServeMux()
	mux.HandleFunc("/users/", func(w http.ResponseWriter, r *http.Request) {
		id := 1 // 简化处理
		user, err := userSvc.GetUser(r.Context(), id)
		if err != nil {
			http.Error(w, err.Error(), http.StatusInternalServerError)
			return
		}
		json.NewEncoder(w).Encode(user)
	})
	return &http.Server{Addr: fmt.Sprintf(":%d", cfg.Port), Handler: mux}, nil
}

var ProviderSet = wire.NewSet(NewServer)

// cmd/server/wire.go
//go:build wireinject

package main

import (
	"net/http"

	"github.com/google/wire"
	"myapp/internal/config"
	"myapp/internal/database"
	"myapp/internal/repository"
	"myapp/internal/service"
	transporthttp "myapp/internal/transport/http"
)

func InitializeServer() (*http.Server, func(), error) {
	wire.Build(
		config.ProviderSet,
		database.ProviderSet,
		repository.ProviderSet,
		service.ProviderSet,
		transporthttp.ProviderSet,
	)
	return nil, nil, nil
}

# 生成注入代码
cd cmd/server && wire

运行 wire 后，Wire 会生成 wire_gen.go，main.go 中 InitializeServer() 的调用会被链接到这个生成的实现。

总结与选型建议

Wire 作为 Go 生态中少有的编译期依赖注入框架，为追求性能和类型安全的项目提供了理想选择。它的核心价值在于：将运行时的反射开销转移到编译期的代码生成，将运行时的依赖缺失错误转移到编译期的显式报错，将手写的初始化逻辑替换为声明式的依赖图描述。

选择 Wire 的场景包括：对启动延迟敏感的应用、需要最小化二进制体积的项目、要将依赖注入与 Clean Architecture 严格分离的团队、以及已经对代码生成工具链（如 protobuf、mockgen）有成熟管理经验的大型组织。

不选择 Wire 而选择运行时 DI（如 FX）的场景包括：需要动态替换依赖（如插件系统）、频繁变更依赖图需要快速调试的初创项目、以及团队更偏好灵活性和开发效率而非极致性能的场景。

在实际使用中，建议遵循以下最佳实践：始终将 wire.go（injector 声明文件）和 wire_gen.go（生成文件）都纳入版本控制，这样团队成员和 CI 无需安装 Wire 也能编译——只需在修改了 Provider 或 injector 后重新运行 wire 并提交变更；保持 Provider 函数签名简单，每个 Provider 只提供一个主要类型；使用 Provider Set 按模块组织依赖，而不是在一个文件中定义所有内容；在大型项目中建立代码审查规则，要求 wire_gen.go 的变更总是对应 wire.go 或 Provider 的变更。

Wire 虽然在 Go 社区中的普及度不如 FX 高，但对于追求工程质量和长期可维护性的团队来说，它是一个值得认真考虑的基础设施选择。配合合理的模块分层和 Clean Architecture 原则，Wire 可以成为构建可扩展 Go 应用的坚实基础。

常见问题与进阶技巧

*Q: 如何处理多个相同类型的依赖？例如我需要两个不同配置的 sql.DB
A: Wire 不支持直接处理两个相同类型的 Provider。推荐方案是定义命名类型：type ReadDB *sql.DB 和 type WriteDB *sql.DB，或者使用结构体包装。然后在 Provider 中做类型转换返回命名类型。

Q: wire_gen.go 的代码变更需要审查吗？
A: 建议审查，但可以快速检查而不是逐行阅读。重点确认依赖顺序是否合理，以及是否有意外新增或删除的 Provider 调用。更推荐的做法是只审查 wire.go 和 Provider 的变更，然后由 CI 验证生成的 wire_gen.go 是最新的。

Q: 在 CI 中如何确保 wire_gen.go 是最新的？
A: 在 CI 流水线中运行 wire check ./... 或 wire gen ./... 并检查 git diff 是否为空。如果有变更说明提交者忘记重新生成，CI 应该失败。

Q: Wire 支持泛型吗？
A: Wire 对泛型的支持有限。泛型类型在 Provider 签名中需要显式实例化，不能直接使用类型参数。如果项目大量使用泛型，可能需要额外注意 Wire 的兼容性。

继续阅读

探索更多技术文章

浏览归档，发现更多关于系统设计、工具链和工程实践的内容。

全部文章返回首页