Go 不需要依赖注入？手把手带你在 Golang 使用像 Java Spring 注解一样的 DI 和 AOP

[justmaplewu]

Java Spring 在易用性和交互体验上足够优秀，同时语言本身也非常适合基于运行时的注入机制。

即使社区已经有很多基于运行时的依赖注入，Go 实际上更多官方推崇的玩法是基于代码生成和静态分析，比如 wire 就是 google 提供的一个依赖注入实现。

但是 wire 在易用性我认为还存在一个使用体验上的问题， 就是需要额外维护 wire.Set 相关的声明，比如：

要利用下列素材组装出以下 Target 这样一个结构体，

type StructA struct{}

type StructB struct {
	InterfaceC
}

type StructC struct {
	StructA
}

func (StructC) Foo() {}

type InterfaceC interface {
	Foo()
}

type Target struct {
	StructA
	StructB
	InterfaceC
}

你必须提供一份额外的声明：

var (
	_Set = wire.NewSet(
		wire.Struct(new(StructA), "*"),

		wire.Struct(new(StructB), "*"),

		wire.Bind(new(InterfaceC), new(*StructC)),
		wire.Struct(new(StructC), "*"),

		wire.Struct(new(Target), "*"),
	)
)

这个需要开发者自行额外维护的声明，我认为也是导致 wire 无法在企业大规模普及落地的一个重要原因。

其核心的交互体验受损在于，用户的对象声明和关系声明会出现空间上的割裂，即使是对同样对象的逻辑，也需要在不同的代码文件中进行维护。

即使额外使用各种中间 wire.NewSet 去组合，也没办法彻底优化这个体验。

可以参考 JAVA Spring 的交互设计 用户只需要在对象添加注解，就能完成声明依赖注入关系的工作。

---

在笔者以往的工作中，都在团队内维护和推广了可以类似 Spring 使用注解自动生成依赖注入声明的工具，这个工具让 wire 变得十分地易用。

因此，团队成功将依赖注入的模式落地到几乎所有的 Golang 项目中，让团队的代码质量和架构设计能力都得到了极大地提升。

在多年的沉淀和整合了其他功能后，这个工具的开源版本就是 Gozz

Gozz 提供的 wire 插件 将会很有效的提升用户使用 wire 的体验和上手难度 ：

基本原理是： 通过对注解额外语法分析，以及注解对象上下文，可以直接推断注入对象的注入方式以及注入参数，然后直接依赖注入框架为生成注入声明。

例如我们刚才提到的上述例子，使用 Gozz 后，可以直接把人工维护的各种 wire.Set 删掉。

反而，只需要在代码上加上注解：

// +zz:wire
type StructA struct{}

// +zz:wire
type StructB struct {
	InterfaceC
}

// +zz:wire:bind=InterfaceC
type StructC struct {
	StructA
}

func (StructC) Foo() {}

type InterfaceC interface {
	Foo()
}

// +zz:wire:inject=./
type Target struct {
	StructA
	StructB
	InterfaceC
}

上面还出现的两个选项意思就是：

bind 表示 进行 interface的绑定

inject 表示为此对象生成目标函数 Injector 以及生成的文件地址

执行 gozz run -p "wire" ${filename} 后

你会发现使用 wire 要额外加的所有东西都被生成好了，而且也自动帮你执行好了 wire

全过程，只需要几条注解 加上 一条命令 你就得到了下面的完整依赖注入函数：

func Initialize_Target() (*Target, func(), error) {
	structA := StructA{}
	structC := &StructC{
		StructA: structA,
	}
	structB := StructB{
		InterfaceC: structC,
	}
	target := &Target{
		StructA:    structA,
		StructB:    structB,
		InterfaceC: structC,
	}
	return target, func() {
	}, nil
}

---

除了自动化的依赖注入之外，Gozz 还可以在依赖注入中进行 AOP ，自动地生成 interface 的动态代理

比如下面这个例子， Interface 绑定了两个类型，其中一个有 aop 选项

最后的 Target 则需要 三种 Interface 来构造，虽然他们其实都是同个类型的别名

type Implement struct{}

// +zz:wire:bind=InterfaceX
// +zz:wire:bind=InterfaceX2:aop
type Interface interface {
	Foo(ctx context.Context, param int) (result int, err error)
	Bar(ctx context.Context, param int) (result int, err error)
}

type InterfaceX Interface
type InterfaceX2 Interface

// +zz:wire:inject=/
type Target struct {
	Interface
	InterfaceX
	InterfaceX2
}

func (Implement) Foo(ctx context.Context, param int) (result int, err error) {
	return
}

func (Implement) Bar(ctx context.Context, param int) (result int, err error) {
	return
}

通过执行 gozz run -p "wire" ./${filename}

会生成 以下的注入，你会发现 InterfaceX2 的注入会被替换成wire02_impl_aop_InterfaceX2

一个自动生成的结构体

// Code generated by Wire. DO NOT EDIT.

//go:generate go run github.com/google/wire/cmd/wire
//+build !wireinject

package wire02

// Injectors from wire_zinject.go:

// github.com/go-zing/gozz-doc-examples/wire02.Target
func Initialize_Target() (*Target, func(), error) {
	implement := &Implement{}
	wire02_impl_aop_InterfaceX2 := &_impl_aop_InterfaceX2{
		_aop_InterfaceX2: implement,
	}
	target := &Target{
		Interface:   implement,
		InterfaceX:  implement,
		InterfaceX2: wire02_impl_aop_InterfaceX2,
	}
	return target, func() {
	}, nil
}

在生成的另一个问题 wire_zzaop.go 可以看到它的定义：

type _aop_interceptor interface {
	Intercept(v interface{}, name string, params, results []interface{}) (func(), bool)
}

// InterfaceX2
type (
	_aop_InterfaceX2      InterfaceX2
	_impl_aop_InterfaceX2 struct{ _aop_InterfaceX2 }
)

func (i _impl_aop_InterfaceX2) Foo(p0 context.Context, p1 int) (r0 int, r1 error) {
	if t, x := i._aop_InterfaceX2.(_aop_interceptor); x {
		if up, ok := t.Intercept(i._aop_InterfaceX2, "Foo",
			[]interface{}{&p0, &p1},
			[]interface{}{&r0, &r1},
		); up != nil {
			defer up()
		} else if !ok {
			return
		}
	}
	return i._aop_InterfaceX2.Foo(p0, p1)
}

func (i _impl_aop_InterfaceX2) Bar(p0 context.Context, p1 int) (r0 int, r1 error) {
	if t, x := i._aop_InterfaceX2.(_aop_interceptor); x {
		if up, ok := t.Intercept(i._aop_InterfaceX2, "Bar",
			[]interface{}{&p0, &p1},
			[]interface{}{&r0, &r1},
		); up != nil {
			defer up()
		} else if !ok {
			return
		}
	}
	return i._aop_InterfaceX2.Bar(p0, p1)
}

简而言之 ，它通过实现了所有的原 Interface 方法对原绑定的调用进行了一层代理封装，并且可以通过代理封装提供所有参数和返回值的指针，以及调用的原始对象和方法名。

只要通过一些指针断言和接口操作，实际上我们就可以：

• 在函数调用进行自定义前置和后置逻辑
• 获取实际调用方及调用方法名
• 对函数参数及返回值进行替换
• 不经过实际调用方，直接终止调用

通过这些功能我们可以实现：

• 检查返回值错误，自动打印错误堆栈及调用信息，自动注入日志、链路追踪、埋点上报等。
• 检查授权状态及访问权限。
• 对调用参数和返回值进行自动缓存。
• 检查或替换 context.Context ，添加超时或检查中断。

这个功能也是社区目前大部分依赖注入框架都没办法做到的，而使用 Gozz 只需要添加一个选项 aop

实际上 gozz 在运行时工具库 gozz-kit 中还提供了工具，可以帮大家生成这种关系依赖图：

比如上面例子的运行时依赖实际上就是：

---

最后一个例子会展示 gozz-wire 的强大兼容性和推断能力：

• 注入值对象
• 使用值对象绑定接口
• 引用类型作为结构体
• 使用指定函数提供注入类型
• 使用结构体字段值进行注入
• 使用 set 对注入进行分组
• 使用额外的原生 wire.NewSet

//go:generate gozz run -p "wire" ./

// provide value and interface value
// +zz:wire:bind=io.Writer:aop
// +zz:wire
var Buffer = &bytes.Buffer{}

// provide referenced type
// +zz:wire
type NullString nullString

type nullString sql.NullString

// use provider function to provide referenced type alias
// +zz:wire
type String = string

func ProvideString() String {
	return ""
}

// provide value from implicit type
// +zz:wire
var Bool = false

// +zz:wire:inject=/
type Target struct {
	Buffer     *bytes.Buffer
	Writer     io.Writer
	NullString NullString
	Int        int
}

// origin wire set
// +zz:wire
var Set = wire.NewSet(wire.Value(Int))

var Int = 0

// mock set injector
// +zz:wire:inject=/:set=mock
type mockString sql.NullString

// mock set string
// provide type from function
// +zz:wire:set=mock
func MockString() String {
	return "mock"
}

// mock set struct type provide fields
// +zz:wire:set=mock:field=*
type MockConfig struct{ Bool bool }

// mock set value
// +zz:wire:set=mock
var mock = &MockConfig{Bool: true}

实际上如此复杂的注入场景，都可以被完美处理：

// github.com/go-zing/gozz-doc-examples/wire03.Target
func Initialize_Target() (*Target, func(), error) {
	buffer := _wireBufferValue
	wire03_aop_io_Writer := _wireBytesBufferValue
	wire03_impl_aop_io_Writer := &_impl_aop_io_Writer{
		_aop_io_Writer: wire03_aop_io_Writer,
	}
	string2 := ProvideString()
	bool2 := _wireBoolValue
	wire03NullString := NullString{
		String: string2,
		Valid:  bool2,
	}
	int2 := _wireIntValue
	target := &Target{
		Buffer:     buffer,
		Writer:     wire03_impl_aop_io_Writer,
		NullString: wire03NullString,
		Int:        int2,
	}
	return target, func() {
	}, nil
}

var (
	_wireBufferValue      = Buffer
	_wireBytesBufferValue = Buffer
	_wireBoolValue        = Bool
	_wireIntValue         = Int
)

// github.com/go-zing/gozz-doc-examples/wire03.mockString
func Initialize_mock_mockString() (mockString, func(), error) {
	string2 := MockString()
	mockConfig := _wireMockConfigValue
	bool2 := mockConfig.Bool
	wire03MockString := mockString{
		String: string2,
		Valid:  bool2,
	}
	return wire03MockString, func() {
	}, nil
}

var (
	_wireMockConfigValue = mock
)

当然 这些强大能力一定程度还是归功于 wire 本身的优秀， Gozz 只是站在了巨人的肩膀上。

以上其实都是 Gozz 提供的示例，在文档页面中都可以找到

而 wire 其实也是 Gozz 提供的强大插件之一，如果使用 Gozz 的其他插件，会得到更加优秀的开发体验和引导你进行更合理的架构设计。

欢迎大家来我们的 Github进行探索，同时给我们提出各种 ISSUE 和 ⭐️

[realpg]

你们搞 java 的就是喜欢把什么都整成 java 的样子

老老实实用 java 不好么

[danbai]

好傻逼

[cI137]

java 传教士

[lasuar]

第一次使用依赖注入，也是一个写过 java 的同事引入的，说实话，真觉得这个玩意儿很影响代码可读性，可维护性。！

[bthulu]

go 不需要依赖注入, go 就是要写成静态的, 这才是 go style, 这才 cool

[Jooeeee]

直接用 java 吧

[justmaplewu]

这就是静态的依赖注入哦

[justmaplewu]

@realpg

首先我不写 JAVA 这种只是借鉴了 JAVA 的交互体验

第二依赖注入不是 JAVA 的专属 而是一种经过工业验证的成熟中大型项目模块组织方式，如果你的代码只是做 demo ，不超过 5000 行或者只有你一个人维护，你可以怎么简陋怎么来

最后，K8s 这些项目的本质都是在用依赖注入的方式来解耦合组装，依赖注入框架只是自动化了这些过程

[ZSeptember]

看起来太复杂了，推荐 uber fx

[GeekGao]

回应标题：Go 不需要依赖注入？ 对，不需要。

[mightybruce]

不如用 Uber fx

[gitrebase]

“依赖注入”应该是种软件工程方法，而不是某些具体的技术实现

此外，我赞同 Go 不需要依赖注入框架，手动进行依赖注入管理比用 wire 之类的代码生成式依赖注入框架要好得多（ wire 这种生成式的给项目代码什么的带来的噪点太大了，见过好几个团队刚用 wire 没过几个月就下掉了）

[justmaplewu]

@gitrebase 是的 依赖注入并不是 JAVA 的专属 使用依赖注入框架其实最重要的优势是 会引导开发去进行接口分离和实现模块的解耦合

对于经验丰富的程序员 可能手动管理依赖可以做得更好 但是鉴于国内的技术水平 不是所有团队都是满配资深 在一个项目 3-5 个应届生的情况 不使用统一依赖注入框架 就是给团队埋屎山

[justmaplewu]

@ZSeptember fx 也是一种很好的依赖注入实现 和 wire 实现的主要区别在于 fx 是在运行时进行依赖组装 虽然灵活，但会有更多不确定性和构造风险， 比如需要更准确的单元测试去保证 所有构造的依赖都被满足 否则会出现生产异常

而 wire 是基于纯静态分析的代码生成 只要生成和编译成功 就不会对线上有任何影响

[777777]

这代码看得我恶心（个人主观）

[justmaplewu]

@777777 这些基本都是自动生成的代码 并不需要人去看或者改