Go 分层架构中的依赖注入：Wire 代码生成实践

最近在学习 Kratos 框架并且尝试使用这个框架将一些服务微服务化，在学习的过程中遇到了一些跟传统的编程思维有一些出入的地方，记录并形成博客，以便帮助更多人快速入门云原生。

一、什么是依赖注入？什么是 Wire？#

依赖注入解决的核心问题#

　　分层架构里，biz 是业务层，里面的逻辑需要查数据库。最直觉的写法是在 biz 里直接 import data 层，自己把对象 new 出来。这样写代码能跑，但 biz 和 data 就绑死了。

　　一旦 data 层的实现发生变更，比如更换数据库、调整 ORM 框架或重构数据访问逻辑，biz 层的代码必须同步修改。而且 biz 内部硬编码了 data 层的具体实现，单元测试时没法 Mock，测试成本极高。

　　依赖注入的做法是：biz 层只声明接口，不 care 谁来实现；data 层去实现这个接口，但 biz 对此无感知。 依赖的具体实例由外部在初始化时传入，而不是由 biz 在内部实例化。

　　通过这种方式，高层与低层之间仅通过接口契约交互。更换底层实现时，biz 代码不用改；进行单元测试时，直接注入 Mock 对象即可。

Wire 的定位与作用#

　　上面说的”外部传入”具体怎么操作？手写 main.go 里的组装逻辑当然可以，但项目大了之后，几十个 NewXxx 的嵌套调用很容易写错顺序，维护起来也头疼。

　　Wire 是 Google 开源的编译期依赖注入代码生成工具。你通过 Provider 函数声明依赖关系，Wire 在编译阶段扫描依赖图，自动生成完整的初始化代码，确保所有依赖被正确实例化且无循环依赖。

　　注意：Wire 不是运行时框架。 它不靠反射，不搞容器，没有启动开销。它只是在编译前帮你生成一个 wire_gen.go 文件，里面就是纯 Go 代码，和你手写的一模一样。生成完之后，Wire 就退场了。

https://github.com/google/wire

Wire 里有三个核心概念，后面代码都会用到，先过一遍：

Provider：就是”我会造某种东西的工厂函数”。你项目里那些 NewXxx 函数，只要返回一个对象，它就是 Provider。
Injector：告诉 Wire”请帮我组装出这个对象”的蓝图文件。里面写 wire.Build(...)，列出所有原材料，Wire 自动算顺序。
ProviderSet：把一堆 Provider 打包成一个集合，省得在 Injector 里一个个列。

二、代码示例#

1. 传统写法：biz 直接 import data#

这是最常见的直觉写法。业务层要查用户，就直接把数据层 import 进来，在构造函数里自己 new 一个 UserMySQLStore。

1
package biz
2

3
import (
4
    "context"
5
    "project/internal/data"  // ← 高层直接依赖低层
6
)
7

8
type UserLogic struct {
9
    store *data.UserMySQLStore  // ← 依赖的是具体实现
10
}
11

12
func NewUserLogic() *UserLogic {
13
    db := data.NewMySQLDatabase("root:password@tcp(localhost:3306)/app")
14
    return &UserLogic{
15
        store: data.NewUserMySQLStore(db),  // ← 自己创建依赖
16
    }
17
}
18

19
func (l *UserLogic) GetUserName(ctx context.Context, id int64) (string, error) {
20
    user, err := l.store.GetByID(ctx, id)
21
    if err != nil {
22
        return "", err
23
    }
24
    return user.Name, nil
25
}

1
package data
2

3
import "context"
4

5
type MySQLDatabase struct {
6
    dsn string
7
}
8

9
func NewMySQLDatabase(dsn string) *MySQLDatabase {
10
    return &MySQLDatabase{dsn: dsn}
11
}
12

13
type UserMySQLStore struct {
14
    db *MySQLDatabase
15
}
16

17
func NewUserMySQLStore(db *MySQLDatabase) *UserMySQLStore {
18
    return &UserMySQLStore{db: db}
19
}
20

21
func (s *UserMySQLStore) GetByID(ctx context.Context, id int64) (*User, error) {
22
    // 真实的 SQL 查询...
23
    return &User{ID: id, Name: "Alice"}, nil
24
}
25

26
type User struct {
27
    ID   int64
28
    Name string
29
}

这段代码的问题很明显。

biz 包里写了 import "project/internal/data"，还直接用了 *data.UserMySQLStore。如果有一天要把 MySQL 换成 MongoDB，biz/user.go 必须改。

NewUserLogic 里硬编码了数据库连接串，连初始化逻辑都耦合在业务层里。调用方只是想拿个业务逻辑对象用，结果它背后默默连了数据库、建了连接池。这在复杂项目里会让初始化逻辑散落得到处都是，main 函数变成一团乱麻。

写单元测试时，你没法在不启动 MySQL 的情况下测 UserLogic，因为 NewUserLogic 内部直接 new 了一个真实的 UserMySQLStore。我们用一张图来看 alt text

2. 依赖倒置：biz 只认接口，data 去实现#

正确的做法是把依赖方向反转。biz 层定义一个 UserStore 接口，声明”我需要什么能力”，但完全不 care 谁来实现。data 层去 import biz，然后提供一个满足这个接口的具体实现。

1
package biz
2

3
import "context"
4

5
// User 领域模型
6
type User struct {
7
    ID   int64
8
    Name string
9
}
10

11
// UserStore 是 biz 层定义的接口
12
// 它只描述"我需要什么"，不描述"怎么实现"
13
type UserStore interface {
14
    GetByID(ctx context.Context, id int64) (*User, error)
15
    Save(ctx context.Context, user *User) error
16
}
17

18
// UserLogic 依赖的是 UserStore 接口，而不是 data 层的任何具体类型
19
type UserLogic struct {
20
    store UserStore
21
}
22

23
// 依赖从外部传入，biz 层自己不创建 store
24
func NewUserLogic(store UserStore) *UserLogic {
25
    return &UserLogic{store: store}
26
}
27

28
func (l *UserLogic) GetUserName(ctx context.Context, id int64) (string, error) {
29
    user, err := l.store.GetByID(ctx, id)
30
    if err != nil {
31
        return "", err
32
    }
33
    return user.Name, nil
34
}

注意上面这个文件里没有任何 import "project/internal/data"。biz 包完全不认识 data 包。

1
package data
2

3
import (
4
    "context"
5
    "project/internal/biz"
6
)
7

8
// MySQLDatabase 封装真实的数据库连接
9
type MySQLDatabase struct {
10
    dsn string
11
}
12

13
func NewMySQLDatabase(dsn string) *MySQLDatabase {
14
    return &MySQLDatabase{dsn: dsn}
15
}
16

17
// userMySQLStore 是 UserStore 接口的一个具体实现
18
// 小写开头，包外不可见，通过 NewUserStore 暴露
19
type userMySQLStore struct {
20
    db *MySQLDatabase
21
}
22

23
// 隐式实现 biz.UserStore 接口，Go 不需要写 implements
24
func (s *userMySQLStore) GetByID(ctx context.Context, id int64) (*biz.User, error) {
25
    // 真实的 SQL 查询逻辑...
26
    return &biz.User{ID: id, Name: "Alice"}, nil
27
}
28

29
func (s *userMySQLStore) Save(ctx context.Context, user *biz.User) error {
30
    // INSERT / UPDATE ...
31
    return nil
32
}
33

34
// NewUserStore 返回的是 biz.UserStore 接口类型
35
// 调用方拿到的是接口，不是具体类型
36
func NewUserStore(db *MySQLDatabase) biz.UserStore {
37
    return &userMySQLStore{db: db}
38
}

这里 data 包 import 了 biz 包。箭头方向彻底反转了。 alt text

3. 解耦之后，测试变得很简单#

因为 UserLogic 依赖的是接口，你可以很轻松地写一个内存版的 Mock 实现来测业务逻辑，完全不需要启动数据库。

1
package biz
2

3
import (
4
    "context"
5
    "testing"
6
)
7

8
// mockUserStore 是一个内存实现的 UserStore，只用于测试
9
type mockUserStore struct {
10
    users map[int64]*User
11
}
12

13
func newMockUserStore() *mockUserStore {
14
    return &mockUserStore{
15
        users: map[int64]*User{
16
            1: {ID: 1, Name: "MockAlice"},
17
        },
18
    }
19
}
20

21
func (m *mockUserStore) GetByID(ctx context.Context, id int64) (*User, error) {
22
    if u, ok := m.users[id]; ok {
23
        return u, nil
24
    }
25
    return nil, context.Canceled // 模拟 not found
26
}
27

28
func (m *mockUserStore) Save(ctx context.Context, user *User) error {
29
    m.users[user.ID] = user
30
    return nil
31
}
32

33
func TestUserLogic_GetUserName(t *testing.T) {
34
    // 用 Mock 创建 UserLogic，完全不涉及 MySQL
35
    logic := NewUserLogic(newMockUserStore())
36

37
    name, err := logic.GetUserName(context.Background(), 1)
38
    if err != nil {
39
        t.Fatal(err)
40
    }
41
    if name != "MockAlice" {
42
        t.Fatalf("expected MockAlice, got %s", name)
43
    }
44
}

在传统写法里，你做不到这一点，因为 NewUserLogic 内部直接 new 了 UserMySQLStore，测试时会被迫连真实数据库。

三、Wire 负责最后的组装#

biz 和 data 都写好了，但它们之间还缺一个”胶水”。

biz 不认识 data，造不出 userMySQLStore；data 虽然能造，但不知道这个实现该给谁。所以必须有一个同时认识两边的第三方来做组装。

没有 Wire 的时候，你只能在 main.go 里手写：

1
func main() {
2
    db := data.NewMySQLDatabase("root:password@tcp(localhost:3306)/app")
3
    store := data.NewUserStore(db)
4
    logic := biz.NewUserLogic(store)
5
    svc := service.NewUserService(logic)
6
    // ...
7
}

项目小的时候，手写这段代码没问题。但一旦层数多了、依赖关系复杂了，main.go 里会挤满 NewA(NewB(NewC(...))) 这种嵌套，而且顺序错一个就编译不过。

Wire 就是自动写这段组装代码的工具。

先安装 Wire：

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

然后写 Injector 蓝图：

1
//go:build wireinject
2
// +build wireinject
3

4
package main
5

6
import (
7
    "github.com/google/wire"
8
    "project/internal/biz"
9
    "project/internal/data"
10
    "project/internal/service"
11
)
12

13
// InitializeApp 告诉 Wire：请用下面这些 Provider，组装出一个 *service.UserService
14
func InitializeApp() (*service.UserService, error) {
15
    wire.Build(
16
        data.NewMySQLDatabase,
17
        data.NewUserStore,
18
        biz.NewUserLogic,
19
        service.NewUserService,
20
    )
21
    return nil, nil
22
}

这里有个细节：为什么文件顶部要写 //go:build wireinject？

因为 wire.Build(...) 这个函数只在 Wire 工具分析时有用。正常 go run 编译时，如果编译器读到这个文件，会因为 wire 包在运行时不可用而报错。所以用 build tag 做区分：

wire.go 带 wireinject tag → 只给 wire 命令分析用
生成的 wire_gen.go 带 !wireinject tag → 正常 go run 时编译

执行 wire 命令后，生成的 wire_gen.go 长这样：

1
// Code generated by Wire. DO NOT EDIT.
2
//这段代码由 Wire 自动生成，不要手动修改
3

4
package main
5

6
import (
7
    "project/internal/biz"
8
    "project/internal/data"
9
    "project/internal/service"
10
)
11

12
func InitializeApp() (*service.UserService, error) {
13
    mySQLDatabase := data.NewMySQLDatabase("root:password@tcp(localhost:3306)/app")
14
    userStore := data.NewUserStore(mySQLDatabase)
15
    userLogic := biz.NewUserLogic(userStore)
16
    userService := service.NewUserService(userLogic)
17
    return userService, nil
18
}

这段代码和你手写 main.go 里的组装逻辑完全一致，但 Wire 自动帮你算好了顺序。项目大了之后，几十个 Provider 的依赖图人工维护很容易出错，Wire 就是用来消除这个心智负担的。

四、各层的 ProviderSet（Kratos 风格）#

实际项目里不会把 Provider 一个个列在 wire.Build 里，而是每层打包成一个 Set。

1
package data
2

3
import "github.com/google/wire"
4

5

6
var ProviderSet = wire.NewSet(
7
    NewMySQLDatabase,
8
    NewUserStore,
9
)

1
package biz
2

3
import "github.com/google/wire"
4

5
var ProviderSet = wire.NewSet(
6
    NewUserLogic,
7
)

1
package service
2

3
import "github.com/google/wire"
4

5
var ProviderSet = wire.NewSet(
6
    NewUserService,
7
)

然后 Injector 里简洁地写：

1
wire.Build(data.ProviderSet, biz.ProviderSet, service.ProviderSet)

Kratos 项目里就是这么干的，每一层一个 ProviderSet，最后在最外层的 cmd/xxx/wire.go 里汇总。

五、几个容易踩的坑#

改了 Provider 没重新执行 wire

wire_gen.go 是自动生成的，如果你改了某个 Provider 的参数或返回值，必须重新执行 wire 命令，否则 wire_gen.go 里的代码还是旧的，编译会报错。

no provider found for X

这个错误意思是 Wire 找不到某个类型的 Provider。检查两点：一是这个类型有没有对应的 NewXxx 函数；二是这个 NewXxx 有没有被加到 wire.Build 或某个 ProviderSet 里。

循环依赖

如果 biz 依赖 data，data 又依赖 biz，Wire 会报循环依赖错误。这也是分层架构的好处：箭头单向，天然避免循环。

六、总结#

依赖注入是一种设计思想，其核心是通过控制反转实现模块解耦。Wire 则是该思想在 Go 语言工程实践中的具体工具实现，负责将手动组装依赖的过程自动化

传统写法：对象自己 new 依赖，高层被低层绑死。
接口解耦：biz 定义契约，data 实现契约，箭头反转。
解耦之后需要有人做组装——以前是人手写 main.go，现在是 Wire 自动生成。

Wire 不创造新的设计模式，它只是把”按依赖顺序调用构造函数”这种枯燥、容易出错的体力活，交给了代码生成器。

如果你正在用 Kratos，或者准备搭一个分层比较清晰的 Go 项目，建议把 Wire 接上。它省下的不是几行代码，而是你在改架构时不用去动那坨初始化逻辑的心力。