本文永久链接 – https://tonybai.com/2023/12/25/go-1-22-foresight

美国时间2023年12月20日，Go官方宣布Go 1.22rc1发布，开启了为期2个多月的、常规的公测之旅，Go 1.22预计将于2024.2月份正式发布！

除了在官网下载Go 1.22rc1版本进行新特性体验之外，我们还可以通过在线的Go Playground选择“Go dev branch”来体验(相比下载安装，在线版本体验会有一些局限)：

注：关于Go的多种安装方法，《Go语言第一课》专栏有系统全面的讲解，欢迎订阅阅读。

本文将和大家一起看看Go 1.22都会带来哪些新特性。不过由于目前为时尚早，下面列出的有些变化最终不一定能进入到Go 1.22的最终版本中，所以切记一切变更点要以最终Go 1.22版本发布时为准。

1. 语言变化

Go 1.22的语言特性变化主要是围绕for loop的。

1.1 loopvar试验特性转正

在Go 1.21版本中，作为试验特性loopvar在Go 1.22中正式转正。如果你还不知道这个特性是啥，我们来看一下下面这个最能说明问题的示例：

// go1.22-foresight/lang/for-range/for_range.go

package main

import (
    "fmt"
    "sync"
)

func main() {
    sl := []int{11, 12, 13, 14, 15}
    var wg sync.WaitGroup
    for i, v := range sl {
        wg.Add(1)
        go func() {
            fmt.Printf("%d : %d\n", i, v)
            wg.Done()
        }()
    }
    wg.Wait()
}

我们分别用Go 1.22rc1和Go 1.21.0来运行上面这段代码：

// 使用go 1.22rc1的运行结果：

$go run for_range.go
4 : 15
1 : 12
0 : 11
3 : 14
2 : 13

// 使用go 1.21.0的运行结果：
$go run for_range.go
4 : 15
4 : 15
4 : 15
4 : 15
4 : 15

之所以存在差异，是因为Go 1.22版本开始，for range语句中声明的循环变量（比如这里的i和v）不再是整个loop一份(loop var per loop)，而是每次iteration都会有自己的变量(loop var per-iteration)，这样在Go 1.22中，for range中的goroutine启动的闭包函数中捕获的变量是loop var per-iteration，这样才会输出5个不同的索引值和对应的切片值。

注：关于Go 1.22版本之前的for range的坑，《Go语言第一课》专栏有图文并茂的原理讲解，欢迎订阅阅读。

那传统的3-clause的for loop呢？其中的循环变量的语义是否也发生变化了呢？我们看下面示例：

// go1.22-foresight/lang/for-range/classic_for_loop.go

package main

import (
    "fmt"
    "sync"
)

func main() {
    sl := []int{11, 12, 13, 14, 15}
    var wg sync.WaitGroup
    for i := 0; i < len(sl); i++ {
        wg.Add(1)
        go func() {
            v := sl[i]
            fmt.Printf("%d : %d\n", i, v)
            wg.Done()
        }()
    }
    wg.Wait()
}

我们依然分别用Go 1.22rc1和Go 1.21.0版本运行这段代码，得到的结果如下：

// 使用go 1.22rc1的运行结果：

$go run classic_for_loop.go
0 : 11
4 : 15
2 : 13
3 : 14
1 : 12

// 使用go 1.21.0的运行结果：

$go run classic_for_loop.go
panic: runtime error: index out of range [5] with length 5

goroutine 20 [running]:
main.main.func1()
    /Users/tonybai/test/go/go1.22-foresight/lang/for-range/classic_for_loop.go:14 +0xc9
created by main.main in goroutine 1
    /Users/tonybai/test/go/go1.22-foresight/lang/for-range/classic_for_loop.go:13 +0x7f
panic: runtime error: index out of range [5] with length 5

goroutine 19 [running]:
main.main.func1()
    /Users/tonybai/test/go/go1.22-foresight/lang/for-range/classic_for_loop.go:14 +0xc9
created by main.main in goroutine 1
    /Users/tonybai/test/go/go1.22-foresight/lang/for-range/classic_for_loop.go:13 +0x7f
exit status 2

从输出结果来看，3-clause的for语句中声明的循环变量也变成了loop var per-iteration了。

在Go 1.22之前，go vet工具在遇到像上面代码那样在闭包中引用循环变量的情况时会给出警告，但由于Go 1.22的这个语义修正，go vet对于Go 1.22及以后版本(根据go.mod中的指示)的类似Go代码将不再报错。

不过就像Russ Cox在spec: less error-prone loop variable scoping这一issue中提及那样，该特性落地可能会带来不兼容问题，即对存量代码行为的破坏性改变。为此Go团队提供了一个名为bisect的工具，该工具可以检测出存量代码在for loop语义发生变更后是否会导致问题。不过该工具似乎只能与go test一起使用，也就是说你只能对那些被Go测试覆盖到的for loop进行检测。

目前spec: less error-prone loop variable scoping这一issue还处于open状态，也没有放入Go 1.22 milestone中，不知道后续是否还会存在变数！

1.2 range支持整型表达式

在Go 1.22版本中，for range后面的range表达式除了支持传统的像数组、切片、map、channel等表达式外，还支持放置整型表达式，比如下面这个例子：

// lang/range-expr-support-integer/main.go

func main() {
    n := 5
    for i := range n {
        fmt.Println(i)
    }
}

我们知道：for range会在执行伊始对range表达式做一次求值，这里对n求值结果为5。按照新增的for range后接整型表达式的语义，对于整数值n，for range每次迭代值会从0到n-1按递增顺序进行。上面代码中的for range会从0迭代到4(5-1)，我们执行一下上述代码就可以印证这一点：

$go run main.go
0
1
2
3
4

如果n <= 0，则循环不运行任何迭代。

这个新语法特性，可以理解为是一种“语法糖”，是下面等价代码的“语法糖”：

for i := 0; i < 5; i++ {
    fmt.Println(i)
}

不过，迭代总是从0开始，似乎限制了该语法糖的使用范围。

1.3 试验特性：range-over-function iterators

在for range支持整型表达式的时候，Go团队也考虑了增加函数迭代器(iterator)，不过前者语义清晰，实现简单。后者展现形式、语义和实现都非常复杂，于是在Go 1.22中，函数迭代器以试验特性提供，通过GOEXPERIMENT=rangefunc可以体验该功能特性。

在没有函数迭代器之前，我们实现一个通用的反向迭代切片的函数可能是像这样：

// lang/range-over-function-iterator/backward_iterate_slice_old.go

func Backward(s []E) func(func(int, E) bool) {
    return func(yield func(int, E) bool) {
        for i := len(s)-1; i >= 0; i-- {
            if !yield(i, s[i]) {
                return
            }
        }
        return
    }
}

下面是在Go 1.21.0版本中使用上面Backward函数的方式：

// lang/range-over-function-iterator/backward_iterate_slice_old.go

func main() {
    sl := []string{"hello", "world", "golang"}
    Backward(sl)(func(i int, s string) bool {
        fmt.Printf("%d : %s\n", i, s)
        return true
    })
}

我们用Go 1.21.0运行一下上述示例：

$go run backward_iterate_slice_old.go
2 : golang
1 : world
0 : hello

在以前版本中，这种对切片、数组或map中进行元素迭代的情况在实际开发中非常常见，也比较模式化，但基于目前语法，使用起来非常不便。于是Go团队提出将它们与for range结合在一起的提案。有了range-over-function iterator机制后，我们就可以像下面这样使用Backward泛型函数了：

// lang/range-over-function-iterator/backward_iterate_slice_new.go

func main() {
    sl := []string{"hello", "world", "golang"}
    for i, s := range Backward(sl) {
        fmt.Printf("%d : %s\n", i, s)
    }
}

相比于上面的老版本代码，这也的代码更简洁清晰了，使用Go 1.22rc1的运行结果也与老版本别无二致：

$GOEXPERIMENT=rangefunc  go run backward_iterate_slice_new.go
2 : golang
1 : world
0 : hello

但代价就是要理解什么样原型的函数才能与for range一起使用实现函数迭代，这的确有些复杂，本文就不展开说了，有兴趣的童鞋可以先看看有关range-over-function iterator的wiki先行了解一下。

2. 编译器、运行时与工具链

2.1 继续增强PGO优化

自Go 1.20版本引入PGO(profile-guided optimization)后，PGO这种优化技术带来的优化效果就得到了持续的提升：Go 1.20实测性能提升仅为1.05%；Go 1.21版本发布时，官方的数据是2%~7%，而Go 1.21编译器自身在PGO优化过后编译速度提升约6%。

在Go 1.22中，官方给出的数字则是2%~14%，这14%的提升想必是来自Google内部的某个实际案例。

2.2 inline和devirtualize

在Go 1.22中，Go编译器可以更灵活的运用devirtualize和inline对代码进行优化了。

在面向对象的编程中，虚拟函数是一种在运行时动态确定调用的函数。当调用虚拟函数时，编译器通常会为其生成一段额外的代码，用于在运行时确定要调用的具体函数。这种动态调度的机制使得程序可以根据实际对象类型来执行相应的函数，但也带来了一定的性能开销。通过devirtualize优化技术，编译器会尝试在编译时确定调用的具体函数，而不是在运行时进行动态调度。这样可以避免运行时的开销，并允许编译器进行更多的优化。

对应到Go来说，就是在编译阶段将使用接口进行的方法调用转换为通过接口的实际类型的实例直接调用该方法。

注：我的《Go语言精进之路》一书中有对通过接口调用方法的原理的详尽说明，欢迎阅读。

关于内联优化，今年Austin Clements发起了inline大修项目，对Go编译器中的内联优化过程进行全面调整，目标是在Go 1.22中拥有更有效的、具有启发能力的内联，为后续内联的进一步增强奠定基础。该大修的成果目前以GOEXPERIMENT=newinliner试验特性的形式在Go 1.22中提供。

2.3 运行时

运行时的变化主要还是来自GC。

Go 1.22中，运行时会将基于类型的垃圾回收的元数据放在每个堆对象附近，从而可以将Go程序的CPU性能提高1-3%。同时，通过减少重复的元数据的优化，内存开销也将降低约1%。不确定减少重复元数据(metadata)这一优化是否来自对unique包的讨论。

2.4 工具链

在Go工具链改善方面，首当其冲的要数go module相关工具了。

在Go 1.22中，go work增加了一个与go mod一致的特性：支持vendor。通过go work vendor，可以将workspace中的依赖放到vendor目录下，同时在构建时，如果module root下有vendor目录，那么默认的构建是go build -mod=vendor，即基于vendor的构建。

go mod init在Go 1.22中将不再考虑GOPATH时代的包依赖工具的配置文件了，比如Gopkg.lock。在Go 1.22版本之前，如果go module之前使用的是类似dep这样的工具来管理包依赖，go mod init会尝试读取dep配置文件来生成go.mod。

go vet工具取消了对loop变量引用的警告，增加了对空append的行为的警告(比如：slice = append(slice))、增加了deferring time.Since的警告以及在log/slog包的方法调用时key-value pair不匹配的警告。

3. 标准库

最后，我们来看看标准库的变化。每次Go发布新版本，标准库都是占更新的大头儿，这里无法将所有变更点一一讲解，仅说说几个重要的变更点。

3.1 增强http.ServerMux表达能力

Go内置电池，从诞生伊始就内置了强大的http库，不过长期以来http原生的ServeMux表达能力比较单一，不支持通配符等，这也是Go社区长期以来一直使用像gorilla/mux、httprouter等第三方路由库的原因。

今年log/slog的作者Jonathan Amsterdam又创建了新的提案：net/http: enhanced ServeMux routing，提高http.ServeMux的表达能力。在新提案中，新的ServeMux将支持如下路由策略(来自http.ServeMux的官方文档)：

• “/index.html”路由将匹配任何主机和方法的路径”/index.html”；
• “GET /static/”将匹配路径以”/static/”开头的GET请求；
• “example.com/”可以与任何指向主机为”example.com”的请求匹配；
• “example.com/{$}”会匹配主机为”example.com”、路径为”/”的请求，即”example.com/”；
• “/b/{bucket}/o/{objectname…}”匹配第一段为”b”、第三段为”o”的路径。名称”bucket”表示第二段，”objectname”表示路径的其余部分。

下面就是基于上面的规则编写的示例代码：

// lib/servemux/main.go

func main() {
    mux := http.NewServeMux()
    mux.HandleFunc("/index.html", func(w http.ResponseWriter, req *http.Request) {
        fmt.Fprintln(w, `match /index.html`)
    })
    mux.HandleFunc("GET /static/", func(w http.ResponseWriter, req *http.Request) {
        fmt.Fprintln(w, `match "GET /static/"`)
    })
    mux.HandleFunc("example.com/", func(w http.ResponseWriter, req *http.Request) {
        fmt.Fprintln(w, `match "example.com/"`)
    })
    mux.HandleFunc("example.com/{$}", func(w http.ResponseWriter, req *http.Request) {
        fmt.Fprintln(w, `match "example.com/{$}"`)
    })
    mux.HandleFunc("/b/{bucket}/o/{objectname...}", func(w http.ResponseWriter, req *http.Request) {
        bucket := req.PathValue("bucket")
        objectname := req.PathValue("objectname")
        fmt.Fprintln(w, `match /b/{bucket}/o/{objectname...}`+":"+"bucket="+bucket+",objectname="+objectname)
    })

    http.ListenAndServe(":8080", mux)
}

我们使用curl对上述示例进行一个测试(前提是在/etc/hosts中设置example.com为127.0.0.1)：

$curl localhost:8080/index.html
match /index.html

$curl example.com:8080/static/abc
match "example.com/"

$curl localhost:8080/static/abc
match "GET /static/"

$curl example.com:8080/
match "example.com/{$}"

$curl example.com:8080/b/mybucket/o/myobject/tonybai
match "example.com/"

$curl localhost:8080/b/mybucket/o/myobject/tonybai
match /b/{bucket}/o/{objectname...}:bucket=mybucket,objectname=myobject/tonybai

从测试情况来看，不同路由设置之间存在交集，这就需要路由匹配优先级规则。新版Go ServeMux规定：如果一个请求有两个或两个以上的模式匹配，则更具体(specific)的模式优先。如果P1符合P2请求的严格子集，也就是说，如果P2符合P1及更多的所有请求，那么P1就比P2更具体。

举个例子：”/images/thumbnails/”比”/images/”更具体，因此两者都可以注册。前者匹配以”/images/thumbnails/”开头的路径，后者则匹配”/images/”子树中的任何其他路径。

如果两者都不更具体，那么模式就会发生冲突。为了向后兼容，这一规则有一个例外：如果两个模式发生冲突，而其中一个模式有主机(host)，另一个没有，那么有主机的模式优先(比如上面测试中的第二次curl执行)。如果通过ServeMux.Handle或ServeMux.HandleFunc设置的模式与另一个已注册的模式发生冲突，这些函数就会panic。

增强后的ServeMux可能会影响向后兼容性，使用GODEBUG=httpmuxgo121=1可以保留原先的ServeMux行为。

3.2 增加math/rand/v2包

在日常开发中，我们多会在生成随机数的场景下使用math/rand包，其他时候使用的较少。但Go 1.22中新增了math/rand/v2包，我之所以将这个列为Go 1.22版本标准库的一次重要变化，是因为这是标准库第一次为某个包建立v2版本包，按照Russ Cox的说法，这次v2包的创建，为标准库中的其他可能的v2包树立了榜样。创建math/rand/v2可以使Go团队能够在一个相对不常用且风险较低的包中解决工具问题（如gopls、goimports等对v2包的支持），然后再转向更常用、风险更高的包，如sync/v2或encoding/json/v2等。

新增rand/v2包的直接原因是清理math/rand并修复其中许多悬而未决的问题，特别是使用过时的生成器、慢速算法以及与crypto/rand冲突的问题，这里就不针对v2包举具体的示例了，对该包感兴趣的同学可以自行阅读该包的在线文档，并探索如何使用v2包。

同时，该提案也为标准库中的v2包的创建建立了一种模式，即v2包是原始包的子目录，并且以原始包的API为起点，每个偏离点都要有明确的理由。

想当初，go module刚落地到Go中时，Go module支持两种识别major的两种方式，一种是通过branch或tag号来识别，另外一种就是利用vN目录来定义新包。当时还不是很理解为什么要有vN目录这种方式，现在从math/rand/v2包的增加来看，足以体现出当初module设计时的前瞻性考量了。

3.3 大修Go execution tracer

Go Execution Tracer是解决Go应用性能方面“疑难杂症”的杀手锏级工具，它可以提供Go程序在一段时间内发生的情况的即时视图。这些信息对于了解程序随时间推移的行为非常宝贵，可辅助开发人员对应用进行性能改进。我曾在《通过实例理解Go Execution Tracer》中对其做过系统的说明。

不过当前版本的Go Execution Tracer在原理和使用方面还存在诸多问题，Google的Michael Knyszek在年初发起了Execution tracer overhaul的提案，旨在对Go Execution Tracer进行改进，使Go Execution Tracer可扩展到大型Go部署的Go执行跟踪。具体目标如下：

• 使跟踪解析所需的内存占用量仅为当前的一小部分。
• 支持可流式传输的跟踪，以便在无需存储的情况下进行分析。
• 实现部分自描述的跟踪，以减少跟踪消费者的升级负担。
• 修复长期存在的错误，并提供一条清理实现的路径。

在近一年的时间里，Knyszek与Felix Geisendorfer、Nick Ripley、Michael Pratt等一起实现了该提案的目标。

鉴于篇幅，这里就不对新版Tracer的使用做展开说明，有兴趣的童鞋可结合《通过实例理解Go Execution Tracer》中的使用方法自行体验新版Tracer。

注：新版Tracer的设计文档 – https://go.googlesource.com/proposal/+/ac09a140c3d26f8bb62cbad8969c8b154f93ead6/design/60773-execution-tracer-overhaul.md

3.4 其他

• “出尔反尔” – syscall包：取消弃用(undeprecate)

自Go 1.4版本以来，syscall包新特性就已经被冻结，并在Go 1.11版本中被标记为不推荐使用(deprecate)。Go团队推荐gopher使用golang.org/x/sys/unix或golang.org/x/sys/windows。syscall包的大多数功能都能被golang.org/x/sys包替代，除了下面这几个：

syscall.SysProcAttr（类型os/exec.Cmd.SysProcAttr)
syscall.Signal（参考文献os.Signal)
syscall.WaitStatus（参考文献os.(*ProcessState).Sys)
syscall.Stat_t
... ...

由于syscall包已经弃用，IDE等工具在开发人员使用上述内容时总是得到警告！这引发了众多开发人员的抱怨。为此，在Go 1.22版本中，syscall取消了弃用状态，但其功能特性依旧保持冻结，不再添加新特性。

• TCPConn to UnixConn：支持zerocopy

gnet作者Andy Pan的提案：TCPConn to UnixConn：支持zerocopy在Go 1.22落地，具体内容可以看一下原始提案issue。

• 新增go/version包

在Go 1.21版本发布后，Go团队对Go语言的版本规则做了调整，并明确了Go语言的向前兼容性和toolchain规则，Go 1.22中增加go/version包实现了按照上述版本规则的Go version判断，这个包既用于go工具链，也可以用于Gopher自行开发的工具中。

4. 小结

Go 1.22版本具有至少两点重要的里程碑意义：

• 通过对loopvar语义的修正，开启了Go已有“语法坑”的fix之路
• 通过math/rand/v2包树立了Go标准库建立vN版本的模式

“语法坑”fix是否能得到社区正向反馈还是一个未知数，其导致的兼容性问题势必会成为Go社区在升级到Go 1.22版本的重要考虑因素，即便决定升级到Go 1.22，严格的代码审查和测试也是必不可少的。

最后，感谢Go团队以及所有Go 1.22贡献者做出的伟大工作！

文本涉及的源码可以在这里下载。

5. 参考资料

-Go 1.22 Milestone – https://github.com/golang/go/milestone/298

“Gopher部落”知识星球旨在打造一个精品Go学习和进阶社群！高品质首发Go技术文章，“三天”首发阅读权，每年两期Go语言发展现状分析，每天提前1小时阅读到新鲜的Gopher日报，网课、技术专栏、图书内容前瞻，六小时内必答保证等满足你关于Go语言生态的所有需求！2023年，Gopher部落将进一步聚焦于如何编写雅、地道、可读、可测试的Go代码，关注代码质量并深入理解Go核心技术，并继续加强与星友的互动。欢迎大家加入！

著名云主机服务厂商DigitalOcean发布最新的主机计划，入门级Droplet配置升级为：1 core CPU、1G内存、25G高速SSD，价格5$/月。有使用DigitalOcean需求的朋友，可以打开这个链接地址：https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻) – https://gopherdaily.tonybai.com

我的联系方式：

• 微博(暂不可用)：https://weibo.com/bigwhite20xx
• 微博2：https://weibo.com/u/6484441286
• 博客：tonybai.com
• github: https://github.com/bigwhite
• Gopher Daily归档 – https://github.com/bigwhite/gopherdaily

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

本文永久链接 – https://tonybai.com/2023/09/28/dependency-injection-with-go

如果你读过Robert C. Martin的《敏捷软件开发：原则、模式与实践》(书的封皮见下图)，那么你一定知道经典的SOLID设计原则中的“D”：依赖倒置原则（Dependency Inversion Principle, DIP）。

依赖倒置原则是面向对象设计中的基本原则之一，它阐述了高层模块和低层模块的依赖关系应该倒置(如下图)，也就是:

• 高层模块不应该依赖低层模块，二者都应该依赖其抽象
• 抽象不应该依赖细节，细节应该依赖抽象

依赖倒置原则实际上就是对控制反转(Inversion of Control，IoC)这一概念的阐述，而依赖注入(Dependency Injection)是实现控制反转的一种机制。所以可以说，依赖倒置原则是设计级的指导思想，它提出了正确的依赖关系；而依赖注入是实现级的具体设计模式，它将组件的依赖关系控制权移到了外部，实现了组件之间的解耦，是对依赖倒置原则的一种实现手段。

依赖注入可以帮助你开发出松耦合的代码，松耦合使代码更易于维护。

在《Go语言包设计指南》一文中，我们提到过：在Go中，耦合发生在包这一层次。而在Go代码层面最低的耦合是接口耦合。在Go中，接口的实现是隐式的，即a包实现b包中定义的接口时是不需要显式导入b包的，我们可以在c包中完成对a包与b包的组装，这样c包依赖a包和b包，但a包与b包之间没有任何耦合。那么负责组装a包与b包的c包能否在代码层面消除掉对a和b的依赖呢？这个就很难了。不过我们可以使用依赖注入技术来消除在代码层面手动基于依赖进行初始化或创建时的复杂性，在中大型的程序中，依赖注入的优点更能得到体现。

在这篇文章中，我们就来聊聊Go中依赖注入可以解决的问题，并初步认识一下两个在Go社区认可度较高的Go依赖注入框架。

1. 手动注入

我们先建立一个符合DIP原则的例子，其依赖关系如下图：

这里有三个“模块”，从高到低分别为Service、BussinessLogic和DatabaseAccess。Service是一个接口，其实现ServiceImpl依赖BussinessLogic接口。Business是BussinessLogic的实现，它还依赖DatabaseAccess接口。Database则是DatabaseAccess接口的实现。

围绕这一示例，我们分别用手动组装和依赖注入框架演示一下如何实现注入，先来看一下手动组装与注入。

下面是示例的项目结构布局：

./manual
└── demo/
    ├── Makefile
    ├── business/
    │   └── business.go
    ├── database/
    │   └── database.go
    ├── go.mod
    ├── main.go
    └── service/
        └── service.go

manual/demo目录下的service、business和database包下面包含了导出的接口与其具体实现的定义。这里将这些包的代码列出来，这些代码在后续应用依赖注入工具的示例中也是保持不变的：

// dependency-injection-examples/manual/demo/service/service.go

package service

import "demo/business"

// Service interface
type Service interface {
    HandleRequest() string
}

// ServiceImpl struct
type ServiceImpl struct {
    logic business.BusinessLogic
}

// Constructor
func NewService(logic business.BusinessLogic) *ServiceImpl {
    return &ServiceImpl{logic: logic}
}

// Implement HandleRequest()
func (s ServiceImpl) HandleRequest() string {
    return "Handled request: " + s.logic.ProcessData()
}

// dependency-injection-examples/manual/demo/business/business.go

package business

import (
    "demo/database"
)

// BusinessLogic interface
type BusinessLogic interface {
    ProcessData() string
}

// Business struct
type Business struct {
    db database.DatabaseAccess
}

// Constructor
func NewBusiness(db database.DatabaseAccess) *Business {
    return &Business{db: db}
}

// Implement ProcessData()
func (b Business) ProcessData() string {
    return "Business logic processed " + b.db.GetData()
}

// dependency-injection-examples/manual/demo/database/database.go

package database

// DatabaseAccess interface
type DatabaseAccess interface {
    GetData() string
}

// Database struct
type Database struct{}

func NewDatabase() *Database {
    return &Database{}
}

// Implement GetData()
func (db Database) GetData() string {
    return "Data from database"
}

service.Service是直面client的接口。于是在main函数中，我们实例化一个Service的实现并传给Client，后者调用Service的HandleRequest方法触发全流程。service.NewService的调用依赖一个实现了business.BusinessLogic接口的实例，我们在调用NewService之前还需要调用business.NewBusiness创建一个实现了business.BusinessLogic接口的实例；business.NewBusiness的调用依赖一个实现了database.DatabaseAccess接口的实例，我们在调用NewBusiness之前需要调用database.NewDatabase创建一个实现了database.DatabaseAccess接口的实例。

这就是手工组装的现实：我们要记住“模块”间的依赖关系，并手动创建对应实例以满足这种依赖。下面是main函数的代码：

// dependency-injection-examples/manual/demo/main.go

package main

import (
    "demo/business"
    "demo/database"
    "demo/service"
    "fmt"
)

// Client struct
type Client struct {
    service service.Service
}

// Constructor
func NewClient(service service.Service) *Client {
    return &Client{service: service}
}

// Call service
func (c Client) MakeRequest() string {
    return "Client request: " + c.service.HandleRequest()
}

func main() {
    // make dependency injection manually
    db := database.NewDatabase()
    busi := business.NewBusiness(db)
    svc := service.NewService(busi)
    client := NewClient(svc)

    fmt.Println(client.MakeRequest())
}

编译运行上述示例的结果如下：

$cd dependency-injection-examples/manual/demo
$make
$./demo
Client request: Handled request: Business logic processed Data from database

这种为了满足依赖而进行的手工实例创建的行为，在一些小型或演示型程序中还可以自诩为straightforward，但在拥有上百个包的大型程序中，这种为了组装而进行的创建行为就会因多点发生、依赖众多而显现出“复杂性”和难于维护。为了保持代码的松耦合还要降低组装创建行为的复杂度，依赖注入工具被引入，并且往往代码库越庞大，引入DI的好处就越发明显。松耦合带来的好处并不总是立竿见影，但随着时间的推移，随着代码库复杂性的增加，这些好处就会变得显而易见。

注：大家不要进入这样的误区：“采用依赖注入工具的代码就一定是符合DIP原则的松耦合的代码”。至少在Go中，不符合DIP原则的代码(比如没有建立接口抽象)也可以使用依赖注入工具来进行依赖的创建和模块间的组装。

Go社区（尤其是一些大厂）提供了一些Go依赖注入工具，比如：Google wire、uber Fx、facebook inject等。这些工具大致可分为两类，一类是利用代码生成技术的编译期依赖注入，另一类则是利用反射技术的运行时依赖注入。

下面我们分别以编译器依赖注入的Google wire和运行时依赖注入的uber fx为例来看看如何通过依赖注入工具来完成依赖模块的组装(assembly)。

注：facebook的inject已经public archived；google wire目前的开发也不是很active，wire团队给出的理由是要保持wire足够简单并认为从v0.3.0开始，wire已经是功能特性完备的了，目前不接受新feature，仅接受bug报告和修复的补丁pr。只有uber的fx还处于非常积极的开发状态，uber宣称fx是经过uber生产验证的：uber几乎所有的Go服务都是建立在Fx基础之上的。

2. google/wire：编译期的依赖注入

wire是由Google Go Cloud开发包团队于2018年下旬开源的Go编译期依赖注入工具，与uber fx、facebook的inject等使用反射在运行时注入不同的是，wire灵感来自Java的Dagger 2，使用的是代码生成技术，而不是反射或服务定位器(service locator)技术。

相较于运行时依赖注入，编译期间注入的最大好处就是生成的依赖注入和组装的代码是对你可见的，没有任何背后的“魔法”。这便于在编译期捕捉到注入过程的错误，也便于代码的调试。

此外，wire团队认为编译期注入可以避免依赖膨胀。Wire生成的代码只会导入所需的依赖项，因此，你的二进制文件不会有未使用的导入。运行时依赖项注入在运行时之前无法识别未使用的依赖项。

下面我们就用wire注入来改造一下上面的示例。

注：安装wire命令为go install github.com/google/wire/cmd/wire@latest 。

相对于manual那个示例，我们在main包下面增加一个新文件wire.go：

// dependency-injection-examples/wire/demo/wire.go

//go:build wireinject
// +build wireinject

package main

// wire.go

import (
    "demo/business"
    "demo/database"
    "demo/service"

    "github.com/google/wire"
)

func InitializeService() service.Service {
    wire.Build(service.NewService,
        wire.Bind(new(service.Service), new(*service.ServiceImpl)),
        business.NewBusiness,
        wire.Bind(new(business.BusinessLogic), new(*business.Business)),
        database.NewDatabase,
        wire.Bind(new(database.DatabaseAccess), new(*database.Database)),
    )
    return nil
}

我们看到wire.go中提供了一个InitializeService函数，用于为main函数中的Client实例提供一个service.Service接口的具体实现。但是在这个函数中我们并没有像manual中那样手工调用NewService等来创建实例，我们仅仅是将各个“模块”Service、BussinessLogic以及DatabaseAccess的实例的创建函数传给了wire.Build函数。另外我们看到wire.go这个源文件使用了build tag，这个文件仅仅是用于代码生成，并不会参与到最终的代码编译过程中，这也是InitializeService函数的返回值随意设置为nil的原因，这个nil在代码生成过程中会被忽略并替换掉。

注：为什么要使用wire.Bind？我们示例中的各个模块的NewXXX函数接受的参数都为接口类型，返回的都是具体的类型实例，这符合Go的惯例。但如果不使用wire.Bind，wire将无法知道NewXXX依赖的接口类型参数该如何创建！通过wire.Bind告诉wire某个接口类型参数，比如service.Service，可由创建如*service.ServiceImpl的类型替代。关于Binding Interfaces的具体介绍，可以参考wire官方文档。

接下来，我们就可以通过wire命令生成代码，完成注入过程：

$cd dependency-injection-examples/wire/demo
$wire
wire: demo: wrote /Users/tonybai/Go/src/github.com/bigwhite/experiments/dependency-injection-examples/wire/demo/wire_gen.go

wire工具基于wire.go生成了wire_gen.go文件，在该示例中，wire_gen.go的内容如下：

// Code generated by Wire. DO NOT EDIT.

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

package main

import (
    "demo/business"
    "demo/database"
    "demo/service"
)

// Injectors from wire.go:

func InitializeService() service.Service {
    databaseDatabase := database.NewDatabase()
    businessBusiness := business.NewBusiness(databaseDatabase)
    serviceImpl := service.NewService(businessBusiness)
    return serviceImpl
}

看一下wire生成的代码，和我们在manual中手动组装的代码基本是一样的。基于这份代码，我们调整一下main函数，主要是去掉手动组装的过程，改为直接调用InitializeService：

// dependency-injection-examples/wire/demo/main.go

func main() {
    // make dependency injection by code generated by wire
    svc := InitializeService()
    client := NewClient(svc)
    fmt.Println(client.MakeRequest())
}

运行一下wire注入这个demo，其结果与manual demo是一致的：

$cd dependency-injection-examples/wire/demo
$make
$./demo
Client request: Handled request: Business logic processed Data from database

关于wire，这里仅是作了“浅尝辄止”的介绍。要想深入了解wire的功能特性，可以阅读Wire tutorial和Wire User Guide。

接下来，我们再来看看如何使用uber/fx来实现依赖注入。

3. uber/fx：运行时的依赖注入

如果我没记错的话，uber应该是先开源的dig，再有的fx。dig是基于反射的依赖注入工具包，而fx则是由dig支撑的依赖注入框架。对应普通Go开发者而言，直接使用fx就对了。

下面是使用fx实现上面示例依赖注入的代码，我们只需要改造一下main.go：

// dependency-injection-examples/fx/demo/main.go

func main() {
    app := fx.New(
        fx.Provide(
            fx.Annotate(
                service.NewService,
                fx.As(new(service.Service)),
            ),
        ),
        fx.Provide(
            fx.Annotate(
                business.NewBusiness,
                fx.As(new(business.BusinessLogic)),
            ),
        ),
        fx.Provide(
            fx.Annotate(
                database.NewDatabase,
                fx.As(new(database.DatabaseAccess)),
            ),
        ),

        fx.Invoke(func(svc service.Service) {
            client := NewClient(svc)
            fmt.Println(client.MakeRequest())
        }),
        fx.NopLogger, // no fx log output
    )

    app.Run()
}

我们在main函数中，使用fx.Provide注册了所有依赖类型的实例的构造方法(NewXXX)，然后将我们要执行的代码放入一个匿名函数，并传给fx.Invoke。当我们运行程序时，fx会在内存中构建对象调用依赖图，并使用Provide中注册的类型实例的构造方法构造实例，完成依赖注入和代码组装，然后运行传给Invoke的函数。

在向fx.Provide传递NewXXX时，我们使用了fx.Annotate，其目的与在wire示例中使用wire.Bind一样，即将一个类型实例转换为接口类型，以满足参数为接口类型的NewXXX的依赖所需。关于fx.Annotate的详细说明，可参考fx的官方文档。

上述使用fx示例还有两处要提及一下，一个是使用fx.NopLogger关闭fx框架自身的日志输出；另外一个则是上述示例run起来后并不会自动退出，只有当按下ctrl+c后，程序才会因收到系统退出信号而退出！

对比fx和wire，你可能也发现了这样一点：fx将很多工作放到了“背后隐蔽处”，如果你不了解fx框架的运行机理，你很难使用好fx框架；而wire生成的代码就是编译到程序中的代码，没有额外的“魔法”。

当然fx不仅提供了Provide、Annotate、Invoke，其他一些功能特性大家可以自行到官方文档阅读并理解使用。

4. 小结

依赖注入常用来解决软件模块之间高度耦合的问题。传统的程序设计中，一个模块直接new或者静态调用另一个模块，这使得模块之间产生了强耦合。依赖注入将模块创建和注入的控制权移交给外部，由外部动态地将某个实现类实例注入到需要它的模块中。这样实现了模块之间的松耦合。

如果你来自Java等面向对象编程语言的群体，你对依赖注入肯定不陌生。

但是在Go社区，我觉得依赖注入并非惯用法。Go社区很多人崇尚“You often don’t need frameworks in Go”这样的信条。但凡引入一个框架，都会带来学习和理解上的额外负担，Go依赖注入框架亦是如此。

究竟是否使用依赖注入，完全取决于你在开发过程中的权衡和取舍。

如果你决定使用依赖注入，wire和fx都是你可选择的框架。就目前情况来看，fx是目前开发最active、历经生产考验最多的Go依赖注入框架，不过要想用好fx，必须深入理解fx的运行机制和底层原理，这又会带来一定的学习负担。

本文涉及的Go源码，可以在这里下载。

5. 参考资料

• 《Dependency Injection：Principles, Practices, and Patterns》 – https://book.douban.com/subject/30932387/
• Compile-time Dependency Injection With Go Cloud’s Wire – https://go.dev/blog/wire
• Wire tutorial – https://github.com/google/wire/blob/main/_tutorial/README.md
• Wire User Guide – https://github.com/google/wire/blob/main/docs/guide.md
• Inversion of Control Containers and the Dependency Injection pattern – https://martinfowler.com/articles/injection.html

“Gopher部落”知识星球旨在打造一个精品Go学习和进阶社群！高品质首发Go技术文章，“三天”首发阅读权，每年两期Go语言发展现状分析，每天提前1小时阅读到新鲜的Gopher日报，网课、技术专栏、图书内容前瞻，六小时内必答保证等满足你关于Go语言生态的所有需求！2023年，Gopher部落将进一步聚焦于如何编写雅、地道、可读、可测试的Go代码，关注代码质量并深入理解Go核心技术，并继续加强与星友的互动。欢迎大家加入！

著名云主机服务厂商DigitalOcean发布最新的主机计划，入门级Droplet配置升级为：1 core CPU、1G内存、25G高速SSD，价格5$/月。有使用DigitalOcean需求的朋友，可以打开这个链接地址：https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式：

• 微博(暂不可用)：https://weibo.com/bigwhite20xx
• 微博2：https://weibo.com/u/6484441286
• 博客：tonybai.com
• github: https://github.com/bigwhite

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。