本文永久链接 – https://tonybai.com/2021/04/09/ten-commandments-of-go

本文翻译自John Arundel的《Ten commandments of Go》。全文如下：

作为一名全职的Go语言作家和老师，我花了很多时间和学生们一起，帮助他们写出更清晰、更好、更有用的Go程序。我发现，我给他们的建议可以归纳总结为一套通用原则，在这里我将这些原则分享给大家。

1. 你应该是无聊的

Go社区喜欢共识(consensus)。比如：Go源代码有一个由gofmt强制执行的统一的代码格式规范。同样，无论你要解决什么问题，通常都有一个标准的、类似于Go行事风格的方法来解决。有时它是标准的方式，因为它是最好的方式，但通常它只是最好的方式，因为它是标准的方式。

要抵制住创意、时尚或（最糟糕的是）聪明的诱惑，这些不是Go的行事风格。Go行事风格的代码简单、无聊，通常相当啰嗦，而且最重要的是显式的风格(由于这个原因，有些人把Go称为面向显式(obviousness-oriented)风格的编程语言)。

当有疑问时，请遵循最小惊喜原则。争取做到一目了然。要直截了当，要简单，要显式，要无聊。

这并不是说在软件工程层面没有展示令人叹为观止的优雅和风格的空间了；当然有。但那是在设计层面上，而不是单个代码行。代码并不重要，它应该以被随时替换。重要的是程序。

2. 你应该以测试为先

在Go中，一个常见的错误是先写了一些函数(比如：GetDataFromAPI)，然后在考虑如何测试它时不知所措。函数通过网络进行了真正的API调用，它向终端打印东西，它写磁盘文件了，这是一个可怕的的不可测试性的坑。

不要先写那个函数，而是先写一个测试(比如：TestGetDataFromAPI)。如何写这样一个测试呢？它必须为函数的调用提供一个本地的TLS测试服务器，所以你需要一种方法来注入这种依赖。它要写数据到io.Writer，你同样需要为此注入一个模拟外部世界的本地依赖，比如：bytes.Buffer。

现在，当你开始编写GetDataFromAPI函数时，一切都将变得很容易了。它的所有依赖关系都被注入，所以它的业务逻辑与它与外部世界的交互和监听方式完全脱钩。

HTTP handler也是如此。一个HTTP handler的唯一工作是解析请求中的数据，将其传递给某个业务逻辑函数来计算结果，并将结果格式化到ResponseWriter。这几乎不需要测试，所以你的大部分测试将在业务逻辑函数本身，而不是handler。我们知道HTTP的工作原理。

3. 你应该测试行为，而不是函数

如果你想知道如何在不实际调用API的情况下测试这个函数，那么答案很简单：”不要测试这个函数”。

你需要测试的不是一些函数，而是一些行为。例如，一个可能是”给定一些用户输入，我可以正确地组合URL并以正确的参数调用API。” 另一个可能是”给定API返回的一些JSON数据，我可以正确地将其解包到某个Go结构体中。”

当你沿着这样的思路考量问题的解决方法的时候，写测试就容易多了：你可以想象一些这类函数，它们每个函数都会接受一些输入，并产生一些输出，并且很容易给它们编写单元测试。有些事情它们是不会做的，例如进行任何HTTP调用。

同样，当你试图实现”数据可以持久地存储在数据库中并从数据库中检索”这样的行为时，你可以将其分解成更小的、更可测试的行为。例如，”给定一个Go结构体，我可以正确地生成SQL查询，并将其内容存储到Postgres表中”，或者 “给定一个对象，我可以正确地将结果解析到Go结构体切片中”。不需要mock数据库，不需要真正的数据库！

4. 你不应制造文书工作

所有的程序都会在某一点上涉及到一些繁琐的、不可避免的数据倒换重组活动；我们可以把所有这类活动归入文书工作的范畴。对程序员来说，唯一的问题是，这些文书工作在API边界的哪一边？

如果是放在用户侧，那就意味着用户必须编写大量的代码来为你的库准备文书工作，然后再编写大量的代码来将结果解压成有用的格式。

相反(将文书工作放在API实现侧)，写零文书工作的库，可以在一行中调用：

game.Run()

不要让用户调用一个构造函数来获取某个对象，然后再基于这个对象进行方法调用。那就是文书工作。只要让一切在他们直接调用时发生就可以了。如果有可配置的设置，请设置合理的默认值，这样用户根本不用考虑，除非他们因为某些原因需要覆盖默认值。功能选项(functional option)是一个很好的模式。

这是另一个先写测试的好理由，如果你写的API中创造了文书工作，那么在测试时你将不得不自己做所有的文书工作，以便使用你自己的库。如果这被证明是笨拙、啰嗦和耗时的，可以考虑将这些文书工作移到API边界内。

5. 你不应该杀死程序

你的库没有权利终止用户的程序。不要在你的包中调用像os.Exit、log.Fatal、panic这样的函数，这不是你能决定的。相反，如果你遇到了不可恢复(recover)的错误，将它们返回给调用者。

为什么不呢？因为它迫使任何想使用你的库的人去写代码，不管panic是否真的被触发。出于同样的原因，你永远不应该使用会引起panic的第三方库，因为一旦你用了，你就需要recover它们。

所以你千万不要显式调用(这些可以杀死程序的函数)，但是隐式调用呢？你所做的任何操作，在某些情况下可能会panic（比如：索引一个空的片断，写入一个空map，类型断言失败）都应该先检查一下是否正常，如果不正常就返回一个错误。

6. 你不要泄露资源

对于一个打算永远运行而不崩溃或出错的程序来说，对其的要求要比对单次命令行工具要严格一些。例如，想想太空探测器：在关键时刻意外重启制导系统，可能会让价值数十亿美元的飞行器驶向星系间的虚空。对于负责的软件工程师来说，这很可能会导致一场没有咖啡的面谈，让人有些不舒服。

我们不是都在为太空器写软件，但我们应该像太空工程师一样思考。自然，我们的程序应该永远不会崩溃（最坏的情况下，它们应该优雅地退化，并提出退出过程的详实信息），但它们也需要是可持续的。这意味着不能泄露内存、goroutines、文件句柄或任何其他稀缺资源。

每当你有一些可泄漏的资源时，当你知道你已经成功获得它的那一刻，你应该想着释放它。无论函数如何退出或何时退出，保证将其清理掉，我们可以用Go带给我们的礼物：defer。

任何时候启动一个goroutine，你都应该知道它是如何结束的。启动它的同一个函数应该负责停止它。使用waitgroups或者errgroups，并且总是向一个可能被取消的函数传递一个context.Context。

7. 你不应该限制用户的选择

我们如何编写友好、灵活、强大、易用的库呢？一种方法是避免不必要地限制用户对库的操作。一个常见的Gopherism(Go主义)是 “接受接口，返回结构”。但为什么这是个好建议呢？

假设你有一个函数，接受类似于一个*os.File的参数 ，并向其写入数据。也许被写入的东西是一个文件并不重要，具体来说，它只需要是一个 “你可以写入的东西”（这个想法由标准库接口，如io.Writer表达）。有很多这样的东西：网络连接、HTTP response writer、bytes.Buffer等等。

通过强迫用户传递给你一个文件，你限制了他们对你的库的使用。通过接受一个接口(如 io.Writer)来代替，你将打开新的可能性，包括尚未被创造的类型，后续它们仍然可以满足(接口) ，可以与你的代码io.Writer一起工作。

为什么要 “返回结构体”？好吧，假设你返回一些接口类型。这极大地限制了用户对该值的操作（他们能做的就是调用其上的方法）。即使他们事实上可以用底层的具体类型做他们需要做的事情，他们也必须先用类型断言来解包它。换句话说，这就是额外的文书工作(应该避免)。

另一种避免限制用户选择的方法是不要使用只有当前Go版本才有的功能。相反，考虑至少支持最近两个主要的Go版本：有些人不能立即升级。

8. 你应该设定边界

让每一个软件组件在自己的内部是完整的、有能力的；不要让它的内部关注点暴露出来，越过它的边界渗入到其他组件中。这一点对于与其他人的代码的边界来说，是双倍的。

例如，假设你的库调用了某个API。这个API会有自己的模式和自己的词汇，反映自己的关注点和自己的领域语言。

边界是那些与你的代码接触的点：例如，调用API并解析其响应的函数。我把它称为 “airlock “函数，因为它的工作部分是确保你的内部类型和关注点不会泄露出去，并防止外来数据泄露进来。

一旦你让一点外来数据在你的程序内部自由运行，它很快就会到处乱跑。你的其他包都需要导入这些外来类型，这很烦人，而且代码将会有一股糟糕的味道。

相反，你的airlock函数应该做两件事：它应该将外来数据转化为你自己的内部格式，而且应该确保数据是有效的。现在，你的所有其他代码只需要处理你的内部类型，它不需要担心数据是否会出错、丢失或不完整。

另一种执行良好边界的方法是始终检查错误。如果你不这样做，无效的数据可能会泄露进来。

9. 你不应该在内部使用接口

一个接口值说：”我不知道这个东西到底是什么，但也许我知道有些事情我可以用它来做。” 这在Go程序中是一种超级不方便的值，因为我们不能做任何没有被接口指定的事情。

对于空接口(interface{})来说，这也是双倍的，因为我们对它一无所知。因此，根据定义，如果你有一个空的接口值，你需要把它类型化为具体的东西才能使用它。

在处理任意数据（也就是在运行时类型或模式未知的数据）时，不得不使用它们是很常见的，比如无处不在的map[string]interface{}。但是，我们应该尽快使用airlock将这一团无知转化为某种具体类型的有用的Go值。

特别是，不要用interface{}类型值来模拟泛型（Go有泛型）。不要写一个函数，接受一些可以是七种具体类型之一的值，然后对其进行类型转换，为该类型找到合适的操作。相反，写七个函数，每个具体类型一个。

不要仅因为你可以在测试中注入mock，就创建一个公共的接口，这是一个错误。创建一个真正的用户在调用你的函数之前必须实现的接口，这违反了“无文书工作原则”。不要在一般情况下写mock；Go不适合这种风格的测试。(当Go中的某些东西很困难时，这通常是你做错事的标志。)

10. 你不要盲目地遵从诫命，而要自己思考

人们说：”告诉我们什么是最佳做法”，仿佛有一本小秘籍，里面有任何技术或组织问题的正确答案。(是有的，但不要说出去。我们不希望每个人都成为顾问)。

小心任何看似清楚、明确、简单地告诉你在某种情况下该怎么做的建议。它不会适用于每一种情况，在适用的地方，它都需要告诫，需要细微的差别，需要澄清。

每个人都希望得到的是不需要真正理解就能应用的建议。但这样的建议比它能带来的帮助更危险：它能让你走到桥的一半，然后你会发现桥是纸做的，而且刚开始下雨。

非常感谢比尔-肯尼迪（Bill Kennedy）和伊南克-古姆斯（Inanc Gumus）对这篇文章的有益评论。

“Gopher部落”知识星球正式转正（从试运营星球变成了正式星球）！“gopher部落”旨在打造一个精品Go学习和进阶社群！高品质首发Go技术文章，“三天”首发阅读权，每年两期Go语言发展现状分析，>每天提前1小时阅读到新鲜的Gopher日报，网课、技术专栏、图书内容前瞻，六小时内必答保证等满足你关于Go语言生态的所有需>求！部落目前虽小，但持续力很强。在2021年上半年，部落将策划两个专题系列分享，并且是部落独享哦：

• Go技术书籍的书摘和读书体会系列
• Go与eBPF系列

欢迎大家加入！

Go技术专栏“改善Go语⾔编程质量的50个有效实践”正在慕课网火热热销中！本专栏主要满足广大gopher关于Go语言进阶的需求，围绕如何写出地道且高质量Go代码给出50条有效实践建议，上线后收到一致好评！欢迎大家订
阅！

我的网课“Kubernetes实战：高可用集群搭建、配置、运维与应用”在慕课网热卖中，欢迎小伙伴们订阅学习！

我爱发短信：企业级短信平台定制开发专家 https://51smspush.com/。smspush : 可部署在企业内部的定制化短信平台，三网覆盖，不惧大并发接入，可定制扩展； 短信内容你来定，不再受约束, 接口丰富，支持长短信，签名可选。2020年4月8日，中国三大电信运营商联合发布《5G消息白皮书》，51短信平台也会全新升级到“51商用消息平台”，全面支持5G RCS消息。

著名云主机服务厂商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
• 微信公众号：iamtonybai
• 博客：tonybai.com
• github: https://github.com/bigwhite
• “Gopher部落”知识星球：https://public.zsxq.com/groups/51284458844544

微信赞赏：

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

本文永久链接 – https://tonybai.com/2021/04/07/go-generics-use-type-sets-to-remove-type-keyword

近日，Go泛型语法负责人之一的Ian Lance Taylor发布了一个issue，说明go团队想引入新的type set概念，并去除原Go泛型方案中置于interface定义中的type list中的type关键字。

对于Go泛型来龙去脉不是很了解的童鞋，可以先去看看我看看我之前的文章：《能力越大，责任越大” – Go语言之父详解将于Go 1.18发布的Go泛型》。在那篇文章的结尾，Go设计团队对自己的Go泛型设计方案中的几个方面给出了自己的满意度评价，其中唯一让团队感觉还不是很完美的就是“Type lists in interfaces”：

1. 何为Type lists in interfaces

我们先来说说何为Type lists in interfaces！当前Go泛型方案使用interface类型用于表达对类型参数(type parameters)的约束(constraints)，比如：

type MyC1 interface {
    M1()
}

func F1[T MyC1](t T) {

}

在上述代码中，我们使用interface MyC1作为类型参数(type parameters)的约束，对于F1函数而言，所有满足MyC1接口的类型都可以作为其类型参数的实参传入：

type MyT1 string
func(t1 *MyT1) M1() {}

var t1 = new(MyT1)
F1(t1)

*MyT1实现了MyC1接口，于是我们可以将其实例(t1)传给F1。Go泛型的自动类型推导会将T的实参置为*MyT1。

完整程序如下：

// https://go2goplay.golang.org/p/WPCvmwkxcEL
package main

import (
    "fmt"
)

type MyC1 interface {
    M1()
}

func F1[T MyC1](t T) {
    fmt.Printf("%T\n", t)
}

type MyT1 string

func (t1 *MyT1) M1() {

}

func main() {
    var t1 = new(MyT1)
    F1(t1) // *main.MyT1
}

对于自定义类型，通过实现接口的方法集合即可满足接口，对于类型参数可以是原生类型的情况，我们无法通过这种方式实现，于是Go团队将type list加入到interface接口中，仅用作泛型类型参数的约束检查：

type MyC2 interface {
    type int, int32, int64
}

func F2[T MyC2](t T) {
    fmt.Printf("%T\n", t)
}

func main() {
    var t2 string
    F2(t2) // string
}

而MyMC2中的：

    type int, int32, int64

就是所谓的”type list”。

如果一个interface定义中既有method也有type list，那么要满足这个interface类型，则作为类型参数实参的类型既必须在type list中（或其underlying type在type list中），又必须实现接口类型的所有方法：

// https://go2goplay.golang.org/p/rE8mGH0lHWm
package main

import (
    "fmt"
)

type MyC3 interface {
    M3()
    type int, string, float64
}

func F3[T MyC3](t T) {
    fmt.Printf("%T\n", t)
}

type MyT3 string

func (t3 MyT3) M3() {

}

func main() {
    t3 := MyT3("hello")
    F3(t3) // main.MyT3
}

细心的童鞋会发现：拥有type list的interface仅能用于做为类型参数的约束，而不能像普通interface类型那样使用：

// https://go2goplay.golang.org/p/mJoEYrceBSL
package main

type MyC3 interface {
    M3()
    type int, string, float64
}

func main() {
    var i3 MyC3 // type checking failed for main
                    // prog.go2:9:9: interface contains type constraints (int, string, float64)
    _ = i3
}

这种gap(缝隙)始终让Go核心团队的开发人员感到“不爽”，那么能否将两者融合在一起呢？即放开对包含type list的interface类型仅能做constraint的限制，让其和普通interface一样使用。这次引入的type set应该是解决这个问题的一个前提。但在这个新proposal中，核心团队还没有将这个问题作为重点，只能算作是为以后留个作业吧。

2. 引入type set概念

Ian Lance Taylor发布的这个issue主要就是想引入type set概念，并用新语法等价替代原泛型proposal中的type list，新语法去除了原type list中的type关键字。

于是go团队试图这样来做：

// 当前的type list
type SignedInteger interface {
    type int, int8, int16, int32, int64
}

// type set理念下的新语法
type SignedInteger interface {
    ~int | ~int8 | ~int16 | ~int32 | ~int64
}

我们看到新语法中去掉了原先type list中的type关键字，类型间的间隔也由逗号改为了管道符|。按该proposal的原意，管道符(在布尔代数中也表示或)更接近于type list的原意，即可以是int，或int8或….。如果仅仅是变成了如下改进的语法：

type SignedInteger interface {
    int | int8 | int16 | int32 | int64
}

估计大家也没多大意见。但是偏偏引入了“~”这个前缀。~int与int有什么区别呢？要搞清楚区别就要先来看看Ian新引入的type set概念了。

什么是type set(类型集合)？Ian给出了此概念的定义：

• 每个类型都有一个type set。
• 非接口类型的类型的type set中仅包含其自身。比如非接口类型T，它的type set中唯一的元素就是它自身：{T}；
• 对于一个普通的、没有type list的普通接口类型来说，它的type set是一个无限集合。所有实现了该接口类型所有方法的类型都是该集合的一个元素，另外由于该接口类型本身也声明了其所有方法，因此接口类型自身也是其Type set的一员。
• 空接口类型interface{}的type set中则是囊括了所有可能的类型；
• 这样一来我们来试试用type set概念重新陈述一下一个类型T实现一个接口类型I：即当类型T是接口类型I的type set的一员时，T便实现了接口I;
• 对于使用嵌入接口类型组合而成的接口类型，其type set就是其所有的嵌入的接口类型的type set的交集。proposal中的举例：type O2 interface{ E1; E2 } ，则02这个接口类型的type set是E1和E2两个接口类型的type set的交集。
• 一个拥有一个method的接口类型，比如：

type MyInterface1 interface {
    MyMethod()
}

可以看成嵌入一个仅包含MyMethod的接口类型的接口类型：

type MyInterface interface {
    MyMethod()
}
type MyInterface1 interface {
    MyInterface
}

• 因此，一个带有自身Method的嵌入其他接口类型的接口类型，比如：

type 03 interface {
    E1
    E2
    MyMethod03()
}

它的type set可以看成E1、E2和E3(type E3 interface { MyMethod03})的type set的交集。

3. 替换type list的新语法方案

我们再回到前面提到的新语法方案：

// type set 新语法
type SignedInteger interface {
    ~int | ~int8 | ~int16 | ~int32 | ~int64
}

Go开发团队给那些用于作为约束或被嵌入到作为约束的接口类型中的接口类型的定义做了重新描述，称这类接口类型的定义中可以嵌入一些额外的结构，被称为interface elements，其组成如下图：

• 图中MyInterface是一个仅用于约束或嵌入到作为约束的接口类型中的类型；
• MyInterface除了拥有自己的方法列表(M1、M2)外，还可以嵌入额外的结构：interface elements，就是T1|T2|~T3|T4…|Tn那一行，这一行即替代了原先方案中的type list;
• interface elements这一行有三个值得关注的事情：
  • T1、T2、T4、Tn这些仅代表type set仅为自身的类型；
  • ~T3的type set 为所有underlying type为T3的类型，~T3被称为approximation elements;
  • 管道符将这些类型连接在一起，共同构成一个union element，该union element的type set为所有这些类型的type set的并集。

好了现在一切都建立在type set这个概念上。那么当上述接口类型作为类型参数的约束时，要想满足该约束，可以作为类型参数的实参，那么传入的类型应该在作为约束的接口类型的type set中。

有了前面关于type set以及接口嵌入的type set的铺垫，作为约束的接口类型的理解就容易多了。无论是单纯的接口类型还是使用嵌入其他接口组合而成的接口类型，亦或是既包括嵌入也拥有自己的method list的接口类型。

4. 问题

Ian的issue一发出就得到了社区的重点关注，并引来的激烈的讨论，但从头看到尾，似乎大家都有些“跑题”，关于这个proposal的真正疑问在于approximation elements身上：

• 是否有必要单独拿出approximation elements这个概念

我们回顾一下当前泛型语法作为约束的接口定义所使用的type list语法，看看当前的type list语法中各个类型是否是仅代表自身？

// https://go2goplay.golang.org/p/5VbaSCQ8-Dq
package main

import (
    "fmt"
)

type S1 struct {
    Name string
    Age  int
}

type S2 S1

type MyC4 interface {
    type struct {
        Name string
        Age  int
    }, int
}

func F4[T MyC4](t T) {
    fmt.Printf("%T\n", t)
}

type MyInt int

func main() {
    var t1 = S1{"tony", 17}
    F4(t1) // main.S1
    var t2 = S2{"tony", 17}
    F4(t2) // main.S2
    var n MyInt = 3
    F4(n) // main.MyInt
}

我们看到作为约束的接口类型MyC4的type list中有两个类型：一个匿名struct和int。之后我们分别使用S1、S2和MyInt作为类型参数的实参，居然都通过了！也就是说当前的type list中的类型按照type set的概念解释，都属于approximation element，只要是underlying type在type list中，那么就可以作为类型参数的实参，通过约束检查。

那就是说：

我们是否可以只将：

type I1 interface {
    type int, string, float64
    ... ...
}

换成：

type I1 interface {
    int | string | float64
    ... ...
}

而无需~这个符号呢？

• 如果~符号是必要的，可否不用~符号？

Go语言中没有使用~运算符，但这个符号在其他主流语言，比如C中是位运算符，而且代表的“非”这个运算符。因此将其用在类型T前面，打眼一看，以为其含义是“不是类型T的类型”。而新proposal则将其用于表示approximation element。这让很多gopher提出异议，希望换一个符号，比如T+等。但目前尚无定论。

5. 小结

能力有限，以上一些对该proposal的理解可能有误，欢迎交流指正。

type set并没有改变什么，只是完成了对interface与实现interface的重新解释。 但是对于后续将interface element用于普通interface类型定义可能有重大的意义。当前的带有interface element的interface类型仅能用于作为泛型类型参数的约束，这与普通interface之间的gap早晚要“填上”，不过这已经不是这个proposal要解决的事情。

从泛型提出到如今，我已经感到泛型的引入极大增加了复杂性 ，即便没有滥用泛型，没有耍奇技淫巧，泛型的引入也让go复杂性陡增。就像这个proposal，认真阅读并理解还是需要花费不少时间和精力的。

“Gopher部落”知识星球正式转正（从试运营星球变成了正式星球）！“gopher部落”旨在打造一个精品Go学习和进阶社群！高品质首发Go技术文章，“三天”首发阅读权，每年两期Go语言发展现状分析，>每天提前1小时阅读到新鲜的Gopher日报，网课、技术专栏、图书内容前瞻，六小时内必答保证等满足你关于Go语言生态的所有需>求！部落目前虽小，但持续力很强。在2021年上半年，部落将策划两个专题系列分享，并且是部落独享哦：

• Go技术书籍的书摘和读书体会系列
• Go与eBPF系列

欢迎大家加入！

Go技术专栏“改善Go语⾔编程质量的50个有效实践”正在慕课网火热热销中！本专栏主要满足>广大gopher关于Go语言进阶的需求，围绕如何写出地道且高质量Go代码给出50条有效实践建议，上线后收到一致好评！欢迎大家订
阅！

我的网课“Kubernetes实战：高可用集群搭建、配置、运维与应用”在慕课网热卖>中，欢迎小伙伴们订阅学习！

我爱发短信：企业级短信平台定制开发专家 https://51smspush.com/。smspush : 可部署在企业内部的定制化短信平台，三网覆盖，不惧大并发接入，可定制扩展； 短信内容你来定，不再受约束, 接口丰富，支持长短信，签名可选。2020年4月8日，中国三大电信运营商联合发布《5G消息白皮书》，51短信平台也会全新升级到“51商用消息平台”，全面支持5G RCS消息。

著名云主机服务厂商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
• 微信公众号：iamtonybai
• 博客：tonybai.com
• github: https://github.com/bigwhite
• “Gopher部落”知识星球：https://public.zsxq.com/groups/51284458844544

微信赞赏：

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