本文翻译自Go社区知名Gopher和博主Dave Cheney的文章《The Zen of Go》。

本文来自我在GopherCon Israel 2020上的演讲。文章很长:) 如果您希望阅读精简版，请移步到the-zen-of-go.netlify.com。

该演讲视频还未上线。如上线，我会把它更新到本文中的。

我应该如何编写出好代码？

我最近一直在思考很多事情，每当反思自己的工作成果时，眼前常会出现一行字幕：我该如何编写出好代码？ 主观上，没人愿意去编写糟糕的代码，那么问题来了：你是怎么知道你编写出好的Go代码了呢？

如果好与坏之间存在连续性，那么我们怎么知道哪些是好的部分？它的特性、属性、标志、模式和惯用法又是什么呢？

Go语言惯用法(idiomatic Go)

这让我走进Go惯用法。说某种东西是惯用的，就是说它遵循了时代的风格。如果某些东西不是惯用的，那它没有遵循流行的风格，感觉不时髦。

更重要的是，对某人说他们的代码不复合惯用法并不能解释为什么这些代码不符合惯用法。为什么会这样？像所有真相一样，答案可以在词典中找到：

idiom (noun): a group of words established by usage as having a meaning not deducible from those of the individual words.
惯用法（名词）：一组由用法确定的且其含义无法从单个单词的含义中推导出来的单词。

惯用法是共享价值观(value)的标志。Go惯用法不是您从书本中学到的东西，而是通过成为社区的一部分而获得的。

Go惯用法字样用多了，便形成了“口头禅”，这引起我的担忧：这种口头禅在许多方面它可能是具有排他性的。比如：有人说“你不能和我们坐在一起。” 但毕竟这不是我们批评某人的代码不符合惯用法时的索要表达的意思，是吧？他们只是没有做对，看起来不对，它没有遵循流行的风格而已。

我认为Go惯用法不是教如何编写好的Go代码的合适机制，因为从根本上说，它仍然告诉某人做错了(译注：这容易引起对方反感)。如果在他们最愿意接受建议的时候，我们给出让他们不感觉疏远的建议是否会更好些？

谚语(Proverbs)

摆脱有问题的惯用法，Gopher们还有哪些其他的文化手工艺品吗？也许我们可以转向Rob Pike精彩的Go 谚语。这些谚语是合适的教学工具吗？它们会告诉Go新手如何编写好的Go代码吗？

总的来说，我不这么认为。这并不是要驳斥Rob Pike的作品。只是像濑越宪作（Segoe Kensaku）的原著一样，Go谚语只是观察，而不是价值观的陈述。我们再次搬出字典：

proverb (noun): a short, well-known pithy saying, stating a general truth or piece of advice.
谚语（名词）：简短而众所周知的俗语，陈述一般的真理或一段忠告。

Go Proverbs的目的是揭示有关语言设计的更深层次的真理，但是像empty interface says nothing这样的建议对于一个来自商没有结构化类型的语言的新手来说有什么用呢？

重要的是要认识到，在一个不断发展的社区中，任何时候学习Go语言的人的数量都远超过那些声称掌握了该语言的人的数量。因此，在这种情况下，谚语可能也不是最佳的教学工具。

工程价值观

丹·卢（Dan Luu）找到了马克·卢科夫斯基（Mark Lucovsky）关于Windows团队在Windows NT-Windows 2000开发阶段时的工程文化的演讲。我之所以提到它，是因为卢科夫斯基将一种文化描述为一种评估设计和权衡取舍的常用方法。

讨论文化的方法有很多，但是就工程文化而言，Lucovsky的描述是恰当的。其中心思想是在未知的设计空间中用价值观指导决策。Windows NT团队的价值观是：可移植性，可靠性，安全性和可扩展性。粗略地说工程价值观就是在这里完成工作的方式。

Go的价值观

Go的显式价值观是什么呢？定义Go程序员解释世界方式的核心信念或哲学又是什么？他们如何发布宣传？他们怎么传授？如何执行？它们又是如何随着时间变化的？

作为新Go程序员，您将如何被灌输Go的工程价值观？或者，你是一位经验丰富的Go专家，你如何将你的价值观传播给“下一代”？就像我们知道的那样，知识传递的过程不是一个可选项。没有新的血液和新的观念，我们的社区将变得短视和枯萎。

其他语言的价值观

为了给我所要了解的场景做铺垫，我们可以先看看其他语言，我们看看它们的工程价值观。

例如，C++（包括其扩展：Rust）认为程序员不必为自己不使用的特性付费。如果程序未使用该语言的某些计算成本昂贵的特性，则不应强迫该程序承担该特性的成本。该价值观从语言扩展到其标准库，并用作判断所有用C++编写的代码设计的标准。

在Java，Ruby和Smalltalk中，一切都是对象的核心价值观驱动着围绕着消息传递，信息隐藏和多态的程序设计风格。在程序中采用过程式或函数式设计风格会被认为是错误的，或者按照Gophers的说法，是不符合惯用法的。

回到我们自己的Go社区，烙印在Go程序员心中的工程价值观是什么呢？在我们社区中的讨论是很容易引战的，因此要从第一条原则衍生出一套价值观念将是一个巨大的挑战。共识很关键，但随着讨论贡献者数量的增加，难度就成倍增加。但是，如果有人已经为我们完成了这些艰苦的工作了呢？

~~Python~~ Go之禅

几十年前，蒂姆·彼得斯（Tim Peters）坐下来写下了PEN-20（Python之禅）。Peters试图记录他认为Guido van Rossum(Python之父)在Python社区扮演的BDFL(仁慈的独裁者)角色时所应用的工程价值观。

在本文的剩余部分中，我将着眼于Python之禅，并问问大家：是否有什么可以用来揭秘Go程序员的工程价值观的？

一个好的package始于一个好名字

让我们从香辛的东西开始

“Namespaces are one honking great idea–let’s do more of those!” The Zen of Python, Item 19
“命名空间是一个很棒的主意-让我们多做些吧！” Python之禅，条款19

这是相当明确的，Python程序员应该使用命名空间，多多益善。

package就是Go语言的命名空间。我怀疑是否有人质疑将组件分组到程序包中利好设计和潜在重用。但关于这么做的正确方法的困惑肯定会有的，尤其是你拥有另一门语言10年的使用经验。

在Go中，每个程序包都应有一个目的/用途，而了解程序包目的/用途的最佳方法是通过其名字-一个名词。包的名字描述了它提供的内容。因此，这里重新解释一下Peters的话：每个Go软件包(package)都应该仅有一个单一的目的/用途。

这不是一个新主意，我已经说了一段时间了，但是为什么要这样做而不是使用将软件包用于细粒度分类的方法呢？为什么，因为变化(change)。

“Design is the art of arranging code to work today, and be changeable forever.” - Sandi Metz
“设计是安排代码以使其至今天仍然可以工作并且永远可以更改的艺术。” - 桑迪·梅斯

变化是我们所从事的游戏的名称(译注：这里的游戏指代程序开发工作)。作为程序员，我们要做的就是管理变变化。当我们做得很好时，我们称之为设计或架构。当我们做得不好时，我们称其为技术债务或遗留代码。

如果你编写的程序对于一组固定的输入可以一次性地完美地工作，那么没人会在乎代码的好坏，因为最终程序的输出才是企业和业务所关心的。

但这是不正确的。软件具有缺陷(bug)，需求变更，输入变更，并且很少有程序被编写为仅执行一次，因此您的程序会随着时间而变化。可能是您要为此承担任务，更有可能是其他人，但是必须更改该代码。有人必须维护该代码。

那么，如何使程序更改变得容易呢？无所不在的接口？使一切变得易于mock？邪恶的依赖注入(译注：作者对DI似乎很排斥，用了带有感情色彩的词汇)？好吧，也许，对于某类程序，但不是很多，这些技术将很有用。但是，对于大多数程序而言，预先设计一些灵活的方法要比工程设计更为重要。

相反，如果我们采取的立场是取代组件而不是增强组件，该怎么办？知道何时需要更换某些物品的最佳方法是什么时候该物品没有按照锡盒/罐头盒上的说明进行操作。

一个好的包始于选择一个好的名字。把你的包名字想象成电梯游说（Elevator pitch，即用极具吸引力的方式简明扼要地阐述自己的观点）， 仅用一个词就可以描述包的内容。当名字不再符合要求时，请查找替代名字。

简单性很重要

“Simple is better than complex.” - The Zen of Python, Item 3
“简单胜于复杂。” - Python之禅，条款3

PEP-20说：简单胜于复杂，我完全同意。几年前，我发布了这条推文:

大多数编程语言开始都是为了简单，但最终只是为了功能强大而努力。— Dave Cheney（@davecheney）2014年12月2日

至少在当时，我的观察是，我想不出一生中使用的哪门语言不标榜着简单。每种新语言都为其固有的简单性提供了理由和诱因。但是，当我研究时，我发现简单性并不是与Go语言同时代的许多现代语言的核心价值观。也许这只是一个便宜的镜头¹，但是可能是这些语言不是很简单，或者它们不认为自己很简单。他们不认为简单是其核心价值观。

但是什么时候简单变得过时了？为什么商业软件开发行业会忘记这个基本原则？

“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.” - C. A. R. Hoare, The Emperor’s Old Clothes, 1980 Turing Award Lecture

“构建软件设计的方式有两种：一种方式是使其变得如此简单，以至于显然没有缺陷，另一种方式是使得它变得如此复杂以至于没有明显的缺陷。第一种方法要困难得多。” - CAR Hoare，皇帝的旧衣，1980年图灵奖演讲

我们知道：简单并不意味着容易。通常，使某些东西易于使用而不是易于构建需要更多的工作。

“Simplicity is prerequisite for reliability.” - Edsger W Dijkstra, EWD498, 18 June 1975
“简单性是可靠性的前提。”-  埃兹格·迪克斯特拉（Essger W Dijkstra），EWD498，1975年6月18日

我们为什么要追求简单？为什么Go程序简单很重要？简单并不意味着粗糙，它意味着可读性和可维护性。简单并不意味着“不复杂”，它意味着可靠，有共鸣且易于理解。

“Controlling complexity is the essence of computer programming.” - Brian W. Kernighan, Software Tools (1976)
“控制复杂性是计算机编程的本质。” - Brian W. Kernighan，软件工具  （1976）

Python是否遵守其简单性的说法尚有争议，但Go坚持将简单性作为核心价值观。我认为我们都可以认同，就Go而言，简单代码比聪明代码更可取。

避免包级别状态

“Explicit is better than implicit.” - The Zen of Python, Item 2
“显式胜于隐式。” - Python的禅宗，第2项

我认为彼得斯在这个地方的抱负胜于实际。Python中的许多内容并不明确；装饰器，dunder方法(译注：不知此为何物)等。毫无疑问，这些特性的功能强大，存在这些特性是有原因的。每个特性都是因某人非常关心的事情，尤其是复杂的特性。但是大量使用这些特性使读者很难预测操作的成本。

好消息是，像Go程序员一样，我们可以选择显式代码。显式可能意味着很多事情，也许您可能认为显式只是一种表达官僚主义和漫长风气的好方法，但这只是肤浅的解释。只关注页面的语法、烦恼行长和自制表达式是一种错误的说法。在我看来，更有价值的地方是与耦合和状态有关。

耦合(coupling)是衡量一件东西依赖另一件东西的数量的方法。如果两件事紧密结合，它们就会一起运动。影响其中一个事物的行为会直接反映在另一个事物中。想象一下，一列火车，每个车厢连在一起；发动机行驶到哪里，车厢就跟随到哪里。

描述耦合的另一种方法是内聚(cohesion)一词。内聚衡量两件事自然地在一起的程度。当我们进行一个内聚的争论，或者一个内聚的团队，它们的所有零件都可以自然装配在一起，就像设计的一样。

为什么耦合很重要？因为就像火车一样，当您需要更改一段代码时，与之紧密相关的所有代码都必须更改。一个再适合不过的例子：有人发布了他们的API的新版本，现在您的代码无法通过编译了。

API是不可避免的耦合源，但是存在更多隐蔽的耦合形式。显然，每个人都知道，如果API的原型发生更改，则该调用的传入和返回数据都会发生变化。就在函数原型中；我采用这些类型的值，并返回其他类型的值。但是，如果API以其他方式传递数据怎么办？如果每次调用此API的结果都是基于上次调用该API的结果，即使您没有更改参数该怎么办？

这是状态，状态管理是计算机科学中的问题。

package counter

var count int

func Increment(n int) int {
        count += n
        return count
}

假设我们有这个简单的counter包。您可以调用Increment以增加计数器，即便传入0，你也可以得到返回值。

假设您必须测试此代码，那么每次测试后如何重置计数器？假设您想并行运行这些测试，可以吗？现在，假设您要为每个程序进行不止一个计数，您可以这样做吗？

不，当然不行。显然，答案是将count变量封装为类型。

package counter

type Counter struct {
        count int
}

func (c *Counter) Increment(n int) int {
        c.count += n
        return c.count
}

现在想象一下，这个问题不局限于计数器，还包括应用程序的主要业务逻辑。您可以单独测试吗？您可以并行测试吗？您一次可以使用多个实例吗？如果回答那些问题为否，则原因是软件的包级别状态。

避免包级别状态。通过提供一种类型需要的依赖项作为该类型上的字段，而不是使用包变量，来减少耦合和怪异的行为。

为失败而计划，而不是成功而计划

“Errors should never pass silently.” - The Zen of Python, Item 10
“错误绝不能默默传递。” - Python之禅，条款10

有人说过，支持异常处理的语言遵循武士原则(Samurai principle)。要么全胜归来，要么(失败)全不回来。在基于异常的语言中，函数仅返回有效结果。如果他们没有成功，那么控制流程将采纳完全不同的路径。

未检查的异常显然是不安全的编程模型。当您不知道哪些语句可能引发异常时，如何在存在错误的情况下编写健壮的代码？Java尝试通过引入checked exception的概念来使异常更安全，据我所知，这种checked exception在另一种主流语言中没有被引入。有很多使用异常的语言，但是除了Java，所有语言都使用未经检查的各种异常(unchecked exception)。

显然，Go选择了不同的路径。Go程序员认为，健壮的程序是由处理失败情况的片段组成的，然后再处理happy path。在Go设计的空间中：服务器程序，多线程程序，处理网络输入的程序，如果要构建可靠的程序，那么处理意外数据、超时、连接失败和损坏的数据必须是程序员的首要任务。

“I think that error handling should be explicit, this should be a core value of the language.” - Peter Bourgon, GoTime #91
“我认为错误处理应该是显式的，这应该是语言的一个核心价值观。” - 彼得·布尔贡（Peter Bourgon），GoTime＃91

我想回应彼得的主张，因为这是本文的动力。我认为Go的成功很大程度上归功于显式的处理错误的方式。Go程序员首先考虑失败情况。我们首先解决如果...怎么办的情况。这导致程序在编写时处理故障，而不是在生产中处理故障。

反复出现的下面代码片段：

if err != nil {
    return err
}

所付出的成本已基本被在故障发生时刻意处理每个故障情况的价值超过了(译者注：上面的重复代码段也是利大于弊)。关键还在于显式处理每个错误的文化价值观。

早点返回，而不是深层嵌套

“Flat is better than nested.” - The Zen of Python, Item 5
“扁平比嵌套更好。” - Python的禅宗，条款5

这是一个明智的建议，而且它来自以缩进作为控制流主要形式的语言。我们如何用Go来解释这个建议呢？gofmt控制Go程序的整体风格(空白与缩进)，因此无需执行任何额外操作。

我之前写过关于package名字的文章，这里可能有一些建议：避免复杂的软件包层次结构。以我的经验，程序员越努力细分和分类Go代码库，他们越有可能陷入包导入循环的死角。

我认为第5项条款建议的最佳应用是函数内的控制流。简而言之，避免需要控制流缩进过深。

“Line of sight is a straight line along which an observer has unobstructed vision.” - May Ryer, "Code: Align the happy path to the left edge" https://medium.com/@matryer/line-of-sight-in-code-186dd7cdea88

“代码行展现给观察者的视觉效果应该是一条畅通的直线。- May Ryer， “代码：将快乐路径对齐到左边缘”

Mat Ryer将这种想法描述为视线编码(line of sight coding )。视线编码意味着：

• 如果不满足前提条件，则使用保护子句尽早返回。
• 将成功的return语句放在函数的末尾，而不是放在条件代码块中。
• 通过提取函数和方法来降低函数的整体缩进级别。

该建议的关键是您所关心的事情，功能所要做的事情永远不会有在屏幕右侧滑出视线的危险。这种风格有一个额外的副作用，您可以避免团队中对行长度的毫无意义的争论。

每次缩进时，都会向程序员堆栈添加另一个先决条件，从而消耗他们的7±2个短期内存插槽之一(译注：7±2指的是人类能短期记忆的事件数量大约是7，±2是个体差异)。将函数的成功执行路径贴近屏幕左手侧，不要深入嵌套。

如果你认为它性能差，请通过基准测试证明

“In the face of ambiguity, refuse the temptation to guess.” - The Zen of Python, Item 12
“面对模棱两可，拒绝猜测的诱惑。” - Python之禅，条款12

编程基于数学和逻辑，这两个概念很少涉及机会元素。但是，作为程序员，我们每天都在猜测许多事情。这个变量有什么作用？此参数有什么作用？如果我在这类传入nil会怎样？如果我调用Register两次会怎样？实际上，现代编程中存在很多猜测，尤其是在使用不是你编写的库时。

“APIs should be easy to use and hard to misuse.”  - Josh Bloch
“API应该易于使用并且不容易被滥用。” - 乔什·布洛赫（Josh Bloch）

我知道的帮助程序员避免猜测的最好方法之一是在构建API时，应专注于默认用例。使调用者尽可能轻松地执行最常见的事情。但是，我过去写过很多关于API设计的文章，所以我对第12项的解释是：不要猜测性能。

尽管您可能考虑到Knuth的建议，但Go语言成功的推动力之一是其高性能的执行。您可以在Go中编写高性能的程序，因此人们会因此选择Go。关于性能有很多误解，所以我的要求是，当您希望对代码进行性能调优时，或者遇到一些教条式的建议时，例如defer缓慢，CGO昂贵，或者始终使用原子操作而不是互斥锁时，请不要猜。

不要因为过时的教条而使您的代码复杂化，并且，如果您认为某些事情很慢，请首先使用基准测试进行证明。Go提供了出色的基准测试和性能分析工具，这些工具均可免费获得。使用它们来找出您程序中的性能瓶颈。

在启动goroutine之前，请知道它何时会停止

在这一点上，我认为我已经从PEP-20中挖掘了有价值的要点，并且可能扩展其重新解释的范围。我认为很好，因为尽管这是一种有用的修辞手法，但最终我们还是在谈论两种不同的语言。

“You type go, a space, and then a function call. Three keystrokes, you can’t make it much shorter than that. Three keystrokes and you’ve just started a sub process.” - Rob Pike, Simplicity is Complicated, dotGo 2015

“您键入go，一个空格和一个函数调用。三次按键，您不能做到比这还短了。三次按键，您就启动了一个子过程。” - 罗伯·派克（Rob Pike），Simplicity is Complicated，dotGo，2015年

接下来的两个建议，我将专注于goroutines。Goroutines是语言的标志性功能，这是我们给出的关于一等公民(first class)并发的答案。它们非常易于使用，只需将单词go放在语句前面，即可异步启动该函数。非常简单，没有线程，没有堆栈大小，没有线程池执行程序(thread pool executor)，没有ID，没有跟踪完成状态。

Goroutines代价很低。由于运行时(runtime)能够将goroutine多路复用到一个小的线程池中（您不必管理），因此可以轻松容纳数十万，数百万个goroutine。这开创了在竞争性并发模型（例如线程或事件回调）下不可行的设计。

但是，即便如goroutine一样便宜，但它们也不是免费的。至少它们的堆栈有几千字节，当您启动10^6个goroutine时，它们的确开始累加。这并不是说就不应该使用数百万个goroutine，如果你的设计需要，可以做。但是当您这样做时，请务必对其进行跟踪，因为10^6数量级的任何东西累计可能消耗的资源都不是少量的。

Goroutines是Go中资源所有权的关键。为了程序有用，goroutine必须做一些事情，这意味着它几乎总是持有对资源的引用或所有权：锁、网络连接、带有数据的缓冲区、channel的发送端。当该goroutine处于活动状态时，将持有锁，保持网络连接打开，保留缓冲区，并且channel的接收器将继续等待更多数据。

释放这些资源的最简单方法是将它们与goroutine的生命周期相关联-当goroutine退出时，资源释放。因此，尽管开始执行goroutine几乎是微不足道的，但在进行三次按键(go+空格)前，请确保您对以下问题有答案：

• goroutine在什么情况下会停止？ Go没有办法告诉goroutine退出。没有停止或终止功能，这是有充分的理由的。如果我们无法命令goroutine停止，则必须礼貌地对其提出要求。这几乎总是归结于channel操作。当channel关闭时，针对一个channel的range loop将退出循环。如果一个channel关闭，它将变为可选(selectable)。从一个goroutine到另一个goroutine的信号最好表示为一个关闭的channel。

• 出现这种情况需要什么？ 如果channel既是在goroutines之间进行通讯的工具，又是它们传达完成信号的机制，那么程序员面临的下一个问题就是，谁将关闭channel，何时会发生？

• 您将使用什么信号知道goroutine已停止？ 当您发出信号告知goroutine要停止时，在将来的某个时间gouroutine停止动作会发生。就人类的感知而言，它可能很快发生，但是计算机每秒执行数十亿条指令，并且从每个goroutine的角度来看，它们的指令执行是不同步的。解决方案通常是使用channel发应答信号或fan-in方法需要的waitgroup。

将并发留给调用者

在您编写的任何严肃的Go程序中，都可能涉及并发。这就提出了一个问题，我们编写的许多库和代码都采用每个连接一个goroutine或采用工作者(worker)模式。您将如何管理这些goroutine的生命周期？

net/http是一个很好的例子。关闭拥有监听套接字的server相对来说是直截了当的，但是从该接受套接字产生的goroutines呢？net/http确实在请求对象中提供了一个上下文(context)对象，该上下文对象可用于向正在监听的代码发出信号，表明应该取消请求(cancel)，从而终止goroutine，但是尚不清楚如何知道何时完成所有这些操作。一种方法是调用context.Cancel，知道取消已经完成是另一回事。²

我想说明的一点net/http是，它是良好实践的反例。由于每个连接都是由net/http.Server类型内部产生的goroutine处理的，因此驻留在程序net/http包外部的程序无法控制接受套接字产生的goroutine。

这是一个仍在不断发展的设计领域，例如go-kit的run.Group和Go团队等努力ErrGroup提供了执行，取消和等待异步运行功能的框架。

这里更大的设计准则是针对库编写者的，或者是任何编写可以异步运行的代码的人，将使用goroutine的责任留给调用者。让调用者选择他们希望如何启动，跟踪和等待函数执行。

编写测试以锁定包API的行为

也许您希望从我这里读到一篇我不咆哮测试的文章。可悲的是，今天不是那天。

测试是关于您的软件做什么和不做什么的契约。程序包级别的单元测试应锁定程序包API的行为。他们用代码描述了程序包承诺要做的事情。如果针对每个输入排列组合都有一个单元测试，那么您已经定义了代码将在代码（而不是文档）中执行的约定 。

通过简单的输入go test，您就可以断言代码是否遵守契约。在任何阶段，您都可以高度自信地知道人们在更改之前所依赖的行为在更改之后将继续有效。

测试会锁定api行为。添加，修改或删除公共api的任何更改都必须包括对其测试的更改。

适度是一种美德

Go是一种简单的语言，只有25个关键字。在某些方面，这使该语言内置的功能脱颖而出。同样，这些是语言销售的功能，轻量级并发，结构化类型。

我想我们所有人都经历过尝试立即使用Go的所有功能所带来的困惑。谁对使用channel如此兴奋以至于他们尽可能多地，尽可能多地使用它们？就我个人而言，我发现结果很难测试，脆弱且最终过于复杂。只有我一个人吗？

我在goroutines上经历了相同的经历，试图将工作分解成很小的单元，我创建了一群难以管理的goroutines，最终观察到我的大多数goroutines总是阻塞等待–代码最终是顺序的，我增加了很多复杂性，几乎没有给现实世界带来任何好处。谁经历过这样的事情？

我在嵌入机制方面(embedding)也有同样的经历。最初，我将其误认为是继承。然后，我通过将已经承担多个职责的复杂类型组合成更复杂的巨大类型重现了创建脆弱的基类问题。

这可能是最不可行的建议，但我认为这一点很重要。建议始终是相同的，所有事情都要适度，Go的特性也不例外。如果可以的话，请不要寻求goroutine或channel，也不要嵌入结构，匿名函数，过渡用package，为每样东西建立接口(interface)，要用简单方法而不是聪明的方法。

可维护性很重要

我想谈谈关于PEP-20的最后一项，

“可读性很重要。” - Python之禅，条款7
“Readability Counts.” - The Zen of Python, Item 7

关于可读性的重要性已经被谈论了很多，不仅在Go语言中，而且在所有编程语言中。像我这样的人，倡导在Go的舞台上使用简单，可读性，清晰度，生产力等词，但最终它们都是一个词的同义词- 可维护性。

真正的目标是编写可维护的代码。原始作者之后的代码可以存活下了。存在的代码不仅可以作为时间点投资，而且可以作为未来价值的基础。不是可读性并不重要，而是可维护性更重要。

Go并不是为聪明人而优化的语言。Go不是一种为了在程序中编写最少行数而进行优化的语言。我们没有针对磁盘上源代码的大小进行优化，也没有针对将程序键入编辑器花费的时间进行优化。而是，我们希望优化我们的代码以使读者清晰(clear)。因为需要维护此代码的人正是读者。

如果您是为自己编写程序，则也许只需要运行一次，或者您是唯一会看到该程序的人，然后程序为您工作。但是，如果这是一个将由多个人贡献的软件，或者将由人们使用足够长的时间以致其需求，功能或运行环境可能发生变化，那么您的目标必须是针对程序的可维护性。如果无法维护软件，则它将被重写；那可能是您的公司最后一次投资Go。

你离开后，您努力实现东西可以维护吗？您今天该如何做才能使某人明天更容易维护您的代码？

我的网课“Kubernetes实战：高可用集群搭建、配置、运维与应用”在慕课网上线了，感谢小伙伴们学习支持！

我爱发短信：企业级短信平台定制开发专家 https://tonybai.com/
smspush : 可部署在企业内部的定制化短信平台，三网覆盖，不惧大并发接入，可定制扩展； 短信内容你来定，不再受约束, 接口丰富，支持长短信，签名可选。

著名云主机服务厂商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

微信赞赏：

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

又到了Go语言新版本的发布时间窗口了！这次的主角是Go 1.10。

曾几何时， 这是很多Gopher在Go 1.8、Go 1.9时猜测是否存在的那个版本，毕竟minor version即将进化到两位数。从Go语言第一封设计mail发出到现在的十年间，尤其是Go语言经历了近几年的爆发式增长，基本奠定了云原生第一语言的位置之后，人们对Go语言有了更多新的、更为深刻的认知，同时对这门编程语言也有了更多的改进和优化的期望。Go2在Gopher心中的位置日益提升，直到Russ Cox在GopherCon 2017上公布了Go core team对Go2的开发策略，我们才意识到：哦，Go1还将继续一段时间，甚至是一段很长的时间。2018年2月，我们将迎来Go 1.10版本。

从Go 1.4版本开始，我自己都没想到我能将“Go x.x中值得关注的几个变化”这个系列一直写到Go 1.10。不过现在看来，这个系列还会继续，以后可能还有Go 1.11、Go 1.12…，甚至是进化到Go2之后的各个版本。

Go从1.0版本发布之日起，便遵守着自己“变与不变”的哲学。不变的是对Go对“Go1 promise of compatibility”的严格遵守，变化的则是对语言性能、运行时、GC、工具以及标准库更为精细和耐心地打磨。这次发布的Go 1.10依然延续着这种理念，将重点的改进放在了运行时、工具以及标准库上。接下来，我就和大家一起看看即将发布的Go 1.10都有哪些值得重点关注的变化。

一、语言

Go language Spec是当前Go语言的唯一语言规范标准，虽然其严谨性与那些以ISO标准形式编写成的语言规范（比如：C语言、C++语言的规范）还有一定差距。因此，对go spec的优化，就是在严谨性方面下功夫。当前spec的主要修订者是Go语言三个设计者之一的Robert Griesemer，他在Go 1.10周期对spec做了较多语言概念严谨性方面的改进。

1、显式定义Representability（可表示性）

在Properties of types and values章节下，Robert Griesemer显式引入了一个新的术语Representability，这里译为可表示性。这一术语的引入并未带来语法的变化，只是为了更精确的阐释规范。Representability的定义明确了当规范中出现“a constant x is representable by a value of type T”时成立的几种条件，尤其是针对浮点类型和复数类型。这里摘录（不翻译）：

A constant x is representable by a value of type T if one of the following conditions applies:

- x is in the set of values determined by T.
- T is a floating-point type and x can be rounded to T's precision without overflow. Rounding uses IEEE 754 round-to-even rules but with an IEEE negative zero further simplified to an unsigned zero. Note that constant values never result in an IEEE negative zero, NaN, or infinity.
- T is a complex type, and x's components real(x) and imag(x) are representable by values of T's component type (float32 or float64).

2、澄清未指定类型的常量作为shift(移位)非常量位操作的左操作数时在某些特定上下文中的类型

虽然不及ISO标准规范严谨，但凡是language spec，理解起来都是有门槛的。这个改进针对的是那些未指定类型的常量，在作为shift非常量位操作的左操作数时，在shift表达式结果作为下标表达式中的下标、切片表达式下标或者make函数调用中的size参数时，这个常量将被赋予int类型。我们还是看个例子更加直观：

// go1.10-examples/spec/untypedconst.go
package main

var (
    s uint = 2
)

func main() {
    a := make([]int, 10)
    a[1.0<<s] = 4
}

上面的例子中，重点看a[1.0 << s] = 4这一行，这一行恰好满足了几个条件：

• 1.0 << s 是一个shift表达式，且作为slide表达式的下标；
• shift表达式所移动的位数为s，s是一个变量，非常量，因此这是一个非常量位的移位操作；
• 1.0是未指定类型的常量(untyped const)，且作为shift表达式左操作数

在Go 1.9.2下面，上面的程序编译结果如下：

// go 1.9.2编译器build：

$go build untypedconst.go
# command-line-arguments
./untypedconst.go:9:7: invalid operation: 1 << s (shift of type float64)

在Go 1.9.2下，1.0这个常量被compiler赋予了float64类型，导致编译出错。在Go 1.10下，根据最新的spec，1.0被赋予了int型，编译则顺利通过。

但一旦脱离了下标这个上下文环境，1.0这个常量依旧会被compiler识别为float64类型，比如下面代码中1.0<<s作为Println的参数就是不符合语法的：

// go1.10-examples/spec/untypedconst.go
package main

import "fmt"

var (
    s uint = 2
)

func main() {
    a := make([]int, 10)
    a[1.0<<s] = 4
    fmt.Println(1.0<<s)
}

// go 1.10rc2编译器build：
 $go build untypedconst.go
# command-line-arguments
./untypedconst.go:12:17: invalid operation: 1 << s (shift of type float64)
./untypedconst.go:12:17: cannot use 1 << s as type interface {} in argument to fmt.Println

3、明确预声明类型(predeclared type)是defined type还是alias type

Go在1.9版本中引入了alias语法，同时引入defined type(以替代named type)和alias type，并使用alias语法对某些predeclared type的实现进行了调整。在Go 1.10 spec中，Griesemer进一步明确了哪些predeclared type是alias type：

目前内置的predeclared type只有两个类型是alias type:

byte        alias for uint8
rune        alias for int32

其余的predeclared type都是defined type。

4、移除spec中对method expression: T.m中T的类型的限制

这次是spec落伍于compiler了。Go 1.9.2就可以顺利编译运行下面的代码：

//go1.10-examples/spec/methodexpression.go
package main

import "fmt"

type foo struct{}
func (foo)f() {
    fmt.Println("i am foo")
}

func main() {
    interface{f()}.f(foo{})
}

但在Go 1.9.2的spec中，对Method expression的定义如下：

Go 1.9.2 spec:

MethodExpr    = ReceiverType "." MethodName .
ReceiverType  = TypeName | "(" "*" TypeName ")" | "(" ReceiverType ")" .

Go 1.9.2的spec说，method expression形式:T.m中的T仅能使用Typename，而非上述代码中type实现。Go 1.10的spec中放开了对method expression中T的限制，使得type的实现也可以作为T调用method，与编译器的实际实现行为同步：

Go 1.10rc2 spec:

MethodExpr    = ReceiverType "." MethodName .
ReceiverType  = Type .

不过目前Go 1.10 rc2 compiler还存在一个问题，我们看一下下面的代码：

//go1.10-examples/spec/methodexpression1.go
package main

func main() {
    (*struct{ error }).Error(nil)
}

使用Go 110rc2构建该源码，得到如下错误：

$go build methodexpression1.go
# command-line-arguments
go.(*struct { error }).Error: call to external function
main.main: relocation target go.(*struct { error }).Error not defined
main.main: undefined: "go.(*struct { error }).Error"

该问题目前已经有issue对应，状态还是Open。

二、工具

Go语言有着让其他主流编程语言羡慕的工具集，每次Go版本更新，工具集都会得到进一步的加强，无论是功能还是从开发者体验方面，都有提升。

1、默认的GOROOT

继Go 1.8版本引入默认的GOPATH后，Go 1.10版本为继续改进Go工具的开发者体验，进一步降低新手的使用门槛，引入了默认GOROOT：即开发者无需显式设置GOROOT环境变量，go程序会自动根据自己所在路径推导出GOROOT的路径。这样一来，Gopher们就可以将下载的Go预编译好的安装包解压放置到任意本地路径下，唯一要做的就是将go二进制程序路径放置到PATH环境变量中。比如我们将go1.10rc2的安装包解压到下面路径下：

➜  /Users/tony/.bin/go1.10rc2 $ls
AUTHORS            LICENSE            VERSION            blog/            lib/            robots.txt
CONTRIBUTING.md        PATENTS            api/            doc/            misc/            src/
CONTRIBUTORS        README.md        bin/            favicon.ico        pkg/            test/

在设置为PATH后，我们通过go env命令查看go自动推导的GOROOT以及其他相关变量的值：

$go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/tony/Library/Caches/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/tony/go"
GORACE=""
GOROOT="/Users/tony/.bin/go1.10rc2"
GOTMPDIR=""
GOTOOLDIR="/Users/tony/.bin/go1.10rc2/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -gno-record-gcc-switches -fno-common"

从输出结果看到，go正确找到了安装路径，并得到了GOROOT信息。

2、增加GOTMPDIR变量

在上面的go env命令输出内容中，我们发现了一个陌生的变量：GOTMPDIR，其值默认为空串。这个GOTMPDIR变量是Go 1.10新引入的变量，用于设置Go tool创建和使用的临时文件的路径的。有人可能会说：这个变量看似没什么必要，直接用系统的/tmp路径就好了啊。但是在/tmp路径中编译和执行编译后的程序至少有两点问题，这些问题实际上在go的issues历史中已经存在许久了：

• 有些机器上/tmp路径下被设置了无执行权限(set noexec)
• 有些机器上/tmp下空间有限

我们知道默认情况下，go build和go run都会在/tmp下设置一个临时WORK目录来编译源码和执行编译后的程序的，从下面的一个最简单的helloworld源码的编译执行过程输出(WORK变量)，我们就能看到这点：

// on ubuntu 16.04

# go run -x hello.go
WORK=/tmp/go-build001434392
mkdir -p $WORK/b001/
... ...
mkdir -p $WORK/b001/exe/
cd .
/root/.bin/go1.10rc2/pkg/tool/linux_amd64/link -o $WORK/b001/exe/hello -importcfg $WORK/b001/importcfg.link -s -w -buildmode=exe -buildid=fcYMWp_1J2Xqgzc_Vdga/UpnEUti07R2GzG8dUU3x/MLkSlJVesZhf2kQUaDUU/fcYMWp_1J2Xqgzc_Vdga -extld=gcc /root/.cache/go-build/9f/9f34be2dbcc3f8a62dd6efd6d35be18ecdcbc49e3c8b52b003ecd72b6264e19e-d
$WORK/b001/exe/hello

我个人就遇到过由于IaaS供应商提供的系统盘（不允许定制和修改）过小，导致系统盘空间满，使得Go应用构建和执行失败的问题。我们来设置一下GOTMPDIR，看看效果。我们将GOTMPDIR设置为~/.gotmp，生效后，重新build上面的那个helloworld代码：

# go build -x hello.go
WORK=/root/.gotmp/go-build452283009
mkdir -p $WORK/b001/
cat >$WORK/b001/importcfg << 'EOF' # internal
... ...
mkdir -p $WORK/b001/exe/
cd .
/root/.bin/go1.10rc2/pkg/tool/linux_amd64/link -o $WORK/b001/exe/a.out -importcfg $WORK/b001/importcfg.link -buildmode=exe -buildid=kO-wBNzMZmfHCKzMDziw/jCGBCt7bcrS5NEN-cR4H/8-du6iTQz8uPH3UC-FtB/kO-wBNzMZmfHCKzMDziw -extld=gcc $WORK/b001/_pkg_.a
/root/.bin/go1.10rc2/pkg/tool/linux_amd64/buildid -w $WORK/b001/exe/a.out # internal
mv $WORK/b001/exe/a.out hello
rm -r $WORK/b001/

可以看到，go tool转移到我们设置的GOTMPDIR下构建和执行了。

3、通过cache实现增量构建，提高go tools性能

Go语言具有较高的编译性能是Go语言最初设计时就确定下来的目标，Go编译器的性能在Go 1.4.3版本达到顶峰，这虽然是得益于其使用C语言实现，但更重要的是其为高性能构建而定义的便于依赖分析的语言构建模型，同时避免了像C/C++那样的重复多次扫描大量头文件的负担。随着Go自举的实现，使用Go语言实现的go compiler性能有较大下降，但即便这样，其编译速度在主流编程语言中仍然是数一数二的。在经过了Go 1.6到Go1.9等多个版本对compiler的优化后，go compiler的编译速度已经恢复到Go 1.4.3 compiler的2/3左右或是更为接近的水平。在Go 1.9版本引入并行编译后，Go team在提升工具性能方面的思路发生了些许变化：不再是一味地进行代码级的性能优化，而是选择通过Cache，重复利用中间结果，实现增量构建，来减少编译构建所用的时间。因此，笔者觉得这个功能是本次Go 1.10最大的变化之一。

1) 概述

Go 1.10版本以前，我们经常通过go build -i来加快Go项目源码的编译速度，其原因在于go build -i首次执行时会将目标所依赖的package安装到$GOPATH/pkg下面(.a文件)，这样后续执行go build时，构建过程将不会重新编译目标文件的依赖包，而是直接链接首次执行build -i时安装的依赖包，以实现加速编译！以gocmpp/examples/client为例，第二次构建所需时间仅为首次构建的四分之一左右：

➜  $GOPATH/src/github.com/bigwhite/gocmpp/examples/client git:(master) ✗ $time go build -i client.go
go build -i client.go  1.34s user 0.34s system 131% cpu 1.274 total
➜  $GOPATH/src/github.com/bigwhite/gocmpp/examples/client git:(master) ✗ $time go build -i client.go
go build -i client.go  0.38s user 0.16s system 116% cpu 0.465 total

只有当目标文件的依赖包的源文件发生变化时（比对源文件的修改时间与.a文件的修改时间作为是否重新编译的判断依据），才会重新编译安装这些依赖包。这有些像Makefile的原理：make工具会比较targets文件和prerequisites文件的修改日期，如果prerequisites文件的日期要比targets文件的日期要新，或者target不存在的话，那么，make就会执行后续定义的命令。

不过即便这样，依然至少有两个问题困扰着Go team和广大Gopher：

• 基于时间戳的比对，并不“合理”
  当某个目标文件的依赖包的源文件内容并未真正发生变化，但“修改时间”发生变化了，比如：添加了一行，保存了；然后又删除了这一行，保存。在这样的情况下，理想的操作是不需要重新编译安装这个依赖包，但目前的go build -i机制会重新编译并安装这个依赖包。

• 增量构建并未实现“常态化”
  以前版本中，默认的不带命令行参数的go build命令是不会安装依赖包的，因此每次执行go build，都会重新编译一次依赖包的源码，并将结果放入临时目录以供最终链接使用。也就是说最为常用的go build并未实现增量编译，社区需要常态化的“增量编译”，进一步提高效率。

Go 1.10引入cache机制来解决上述问题。从1.10版本开始，go build tool将维护一个package编译结果的缓存以及一些元数据，缓存默认位于操作系统指定的用户缓存目录中，其中数据用于后续构建重用；不仅go build支持“常态化”的增量构建，go test也支持在特定条件下缓存test结果，从而加快执行测试的速度。

b) go build with cache

我们先来直观的看看go 1.10 build带来的效果，初始情况cache为空：

以我的一个小项目gocmpp为例，用go 1.10第一次build该项目：

➜  $GOPATH/src/github.com/bigwhite/gocmpp git:(master) ✗ $time go build
go build  1.22s user 0.43s system 175% cpu 0.939 total

我们再来构建一次：

➜  $GOPATH/src/github.com/bigwhite/gocmpp git:(master) ✗ $time go build
go build  0.12s user 0.16s system 155% cpu 0.182 total

0.12s vs. 1.22s！通过cache进行的build将构建时间压缩为原来的1/10！为了弄清楚go build幕后行为，我们清除一下cache(go clean -cache)，再重新build，这次我们通过-v -x 输出详细构建过程：

首次编译的详细输出信息：

➜  $GOPATH/src/github.com/bigwhite/gocmpp git:(master) ✗ $go build -x -v
WORK=/var/folders/2h/xr2tmnxx6qxc4w4w13m01fsh0000gn/T/go-build735203690
github.com/bigwhite/gocmpp/vendor/golang.org/x/text/encoding/internal/identifier
mkdir -p $WORK/b033/
cat >$WORK/b033/importcfg << 'EOF' # internal
# import config
EOF
cd $(GOPATH)/src/github.com/bigwhite/gocmpp/vendor/golang.org/x/text/encoding/internal/identifier
/Users/tony/.bin/go1.10rc2/pkg/tool/darwin_amd64/compile -o $WORK/b033/_pkg_.a -trimpath $WORK/b033 -p github.com/bigwhite/gocmpp/vendor/golang.org/x/text/encoding/internal/identifier -complete -buildid iZWJNg2FYmWoSCXb640o/iZWJNg2FYmWoSCXb640o -goversion go1.10rc2 -D "" -importcfg $WORK/b033/importcfg -pack -c=4 ./identifier.go ./mib.go
/Users/tony/.bin/go1.10rc2/pkg/tool/darwin_amd64/buildid -w $WORK/b033/_pkg_.a # internal
cp $WORK/b033/_pkg_.a /Users/tony/Library/Caches/go-build/14/14223040d851359359b0e531555a47e22f5dbd4bf434acc136a7c70c1fc3663f-d # internal
github.com/bigwhite/gocmpp/vendor/golang.org/x/text/transform
mkdir -p $WORK/b031/
cat >$WORK/b031/importcfg << 'EOF' # internal
# import config
packagefile bytes=/Users/tony/.bin/go1.10rc2/pkg/darwin_amd64/bytes.a
packagefile errors=/Users/tony/.bin/go1.10rc2/pkg/darwin_amd64/errors.a
packagefile io=/Users/tony/.bin/go1.10rc2/pkg/darwin_amd64/io.a
packagefile unicode/utf8=/Users/tony/.bin/go1.10rc2/pkg/darwin_amd64/unicode/utf8.a
EOF

.... ....

cd $(GOPATH)/src/github.com/bigwhite/gocmpp
/Users/tony/.bin/go1.10rc2/pkg/tool/darwin_amd64/compile -o $WORK/b001/_pkg_.a -trimpath $WORK/b001 -p github.com/bigwhite/gocmpp -complete -buildid 6LaoHtjkFhandbEhv7zD/6LaoHtjkFhandbEhv7zD -goversion go1.10rc2 -D "" -importcfg $WORK/b001/importcfg -pack -c=4 ./activetest.go ./client.go ./conn.go ./connect.go ./deliver.go ./fwd.go ./packet.go ./receipt.go ./server.go ./submit.go ./terminate.go
/Users/tony/.bin/go1.10rc2/pkg/tool/darwin_amd64/buildid -w $WORK/b001/_pkg_.a # internal
cp $WORK/b001/_pkg_.a /Users/tony/Library/Caches/go-build/e0/e02a5fec0835ca540b62053fdea82589e686e88bf48f18355ed38d41ad19f334-d # internal

再次编译的详细输出信息：

$go build -x -v
WORK=/var/folders/2h/xr2tmnxx6qxc4w4w13m01fsh0000gn/T/go-build906548554

我们来分析一下。首次构建时，我们看到gocmpp依赖的每个包以及自身的包都会被编译，并被copy到/Users/tony/Library/Caches/go-build/下面的某个目录下，包括最终的gocmpp包也是这样。第二次build时，我们看到仅仅输出一行信息，这是因为go compiler在cache中找到了gocmpp包对应的编译好的缓存结果，无需进行实际的编译了。

前面说过，go 1.10 compiler决定是否重新编译包是content based的，而不是依照时间戳比对来决策。我们来修改一个gocmpp包中的文件fwd.go，删除一个空行，再恢复这个空行，保存退出。我们再来编译一下gocmpp:

➜  $GOPATH/src/github.com/bigwhite/gocmpp git:(master) ✗ $go build -x -v
WORK=/var/folders/2h/xr2tmnxx6qxc4w4w13m01fsh0000gn/T/go-build857409409

可以看到go compiler并没有重新编译任何包。如果我们真实改变了fwd.go的内容，比如删除一个空行，保存后再次编译：

➜  $GOPATH/src/github.com/bigwhite/gocmpp git:(master) ✗ $go build -x -v
WORK=/var/folders/2h/xr2tmnxx6qxc4w4w13m01fsh0000gn/T/go-build437927548
github.com/bigwhite/gocmpp
mkdir -p $WORK/b001/
cat >$WORK/b001/importcfg << 'EOF' # internal
# import config
packagefile bytes=/Users/tony/.bin/go1.10rc2/pkg/darwin_amd64/bytes.a
packagefile crypto/md5=/Users/tony/.bin/go1.10rc2/pkg/darwin_amd64/crypto/md5.a
packagefile encoding/binary=/Users/tony/.bin/go1.10rc2/pkg/darwin_amd64/encoding/binary.a
packagefile errors=/Users/tony/.bin/go1.10rc2/pkg/darwin_amd64/errors.a
packagefile fmt=/Users/tony/.bin/go1.10rc2/pkg/darwin_amd64/fmt.a
packagefile github.com/bigwhite/gocmpp/utils=/Users/tony/Test/GoToolsProjects/pkg/darwin_amd64/github.com/bigwhite/gocmpp/utils.a
packagefile io=/Users/tony/.bin/go1.10rc2/pkg/darwin_amd64/io.a
packagefile log=/Users/tony/.bin/go1.10rc2/pkg/darwin_amd64/log.a
packagefile net=/Users/tony/.bin/go1.10rc2/pkg/darwin_amd64/net.a
packagefile os=/Users/tony/.bin/go1.10rc2/pkg/darwin_amd64/os.a
packagefile strconv=/Users/tony/.bin/go1.10rc2/pkg/darwin_amd64/strconv.a
packagefile strings=/Users/tony/.bin/go1.10rc2/pkg/darwin_amd64/strings.a
packagefile sync=/Users/tony/.bin/go1.10rc2/pkg/darwin_amd64/sync.a
packagefile sync/atomic=/Users/tony/.bin/go1.10rc2/pkg/darwin_amd64/sync/atomic.a
packagefile time=/Users/tony/.bin/go1.10rc2/pkg/darwin_amd64/time.a
EOF
cd /Users/tony/Test/GoToolsProjects/src/github.com/bigwhite/gocmpp
/Users/tony/.bin/go1.10rc2/pkg/tool/darwin_amd64/compile -o $WORK/b001/_pkg_.a -trimpath $WORK/b001 -p github.com/bigwhite/gocmpp -complete -buildid trn5lvvRTk_UP3LcT5CC/trn5lvvRTk_UP3LcT5CC -goversion go1.10rc2 -D "" -importcfg $WORK/b001/importcfg -pack -c=4 ./activetest.go ./client.go ./conn.go ./connect.go ./deliver.go ./fwd.go ./packet.go ./receipt.go ./server.go ./submit.go ./terminate.go
/Users/tony/.bin/go1.10rc2/pkg/tool/darwin_amd64/buildid -w $WORK/b001/_pkg_.a # internal
cp $WORK/b001/_pkg_.a /Users/tony/Library/Caches/go-build/7a/7a5671578ed30b125257fd16d0f0b8ceaefd0acc3e44f082ffeecea9f1895499-d # internal

Go compiler发现了内容的变动，对gocmpp包的变动内容进行了重新compile。

c) 缓存目录探索

在增加cache机制时，go tools增加了GOCACHE变量，通过go env GOCACHE查看变量值：

$go env GOCACHE
/Users/tony/Library/Caches/go-build

如果未重设环境变量GOCACHE，那么默认在Linux上，GOCACHE=”~/.cache/go-build”; 在Mac OS X上，GOCACHE=”/Users/UserName/Library/Caches/go-build”。在 OS X上，我们进入$GOCACHE目录，映入眼帘的是：

➜  /Users/tony/Library/Caches/go-build $ls
00/        18/        30/        48/        60/        78/        90/        a7/        bf/        d7/        ef/
01/        19/        31/        49/        61/        79/        91/        a8/        c0/        d8/        f0/
02/        1a/        32/        4a/        62/        7a/        92/        a9/        c1/        d9/        f1/
03/        1b/        33/        4b/        63/        7b/        93/        aa/        c2/        da/        f2/
04/        1c/        34/        4c/        64/        7c/        94/        ab/        c3/        db/        f3/
05/        1d/        35/        4d/        65/        7d/        95/        ac/        c4/        dc/        f4/
06/        1e/        36/        4e/        66/        7e/        96/        ad/        c5/        dd/        f5/
07/        1f/        37/        4f/        67/        7f/        97/        ae/        c6/        de/        f6/
08/        20/        38/        50/        68/        80/        98/        af/        c7/        df/        f7/
09/        21/        39/        51/        69/        81/        99/        b0/        c8/        e0/        f8/
0a/        22/        3a/        52/        6a/        82/        9a/        b1/        c9/        e1/        f9/
0b/        23/        3b/        53/        6b/        83/        9b/        b2/        ca/        e2/        fa/
0c/        24/        3c/        54/        6c/        84/        9c/        b3/        cb/        e3/        fb/
0d/        25/        3d/        55/        6d/        85/        9d/        b4/        cc/        e4/        fc/
0e/        26/        3e/        56/        6e/        86/        9e/        b5/        cd/        e5/        fd/
0f/        27/        3f/        57/        6f/        87/        9f/        b6/        ce/        e6/        fe/
10/        28/        40/        58/        70/        88/        README        b7/        cf/        e7/        ff/
11/        29/        41/        59/        71/        89/        a0/        b8/        d0/        e8/        log.txt
12/        2a/        42/        5a/        72/        8a/        a1/        b9/        d1/        e9/        trim.txt
13/        2b/        43/        5b/        73/        8b/        a2/        ba/        d2/        ea/
14/        2c/        44/        5c/        74/        8c/        a3/        bb/        d3/        eb/
15/        2d/        45/        5d/        75/        8d/        a4/        bc/        d4/        ec/
16/        2e/        46/        5e/        76/        8e/        a5/        bd/        d5/        ed/
17/        2f/        47/        5f/        77/        8f/        a6/        be/        d6/        ee/

熟悉git原理的朋友一定觉得这个目录组织结构似曾相识！没错，在每个git项目的./git/object目录下，我们也能看到下面的结果：

.git/objects git:(master) $ls
00/    0c/    18/    24/    30/    3c/    48/    54/    60/    6c/    78/    84/    90/    9c/    a8/    b4/    c0/    cc/    d8/    e4/    f0/    fc/
01/    0d/    19/    25/    31/    3d/    49/    55/    61/    6d/    79/    85/    91/    9d/    a9/    b5/    c1/    cd/    d9/    e5/    f1/    fd/
02/    0e/    1a/    26/    32/    3e/    4a/    56/    62/    6e/    7a/    86/    92/    9e/    aa/    b6/    c2/    ce/    da/    e6/    f2/    fe/
03/    0f/    1b/    27/    33/    3f/    4b/    57/    63/    6f/    7b/    87/    93/    9f/    ab/    b7/    c3/    cf/    db/    e7/    f3/    ff/
04/    10/    1c/    28/    34/    40/    4c/    58/    64/    70/    7c/    88/    94/    a0/    ac/    b8/    c4/    d0/    dc/    e8/    f4/    info/
05/    11/    1d/    29/    35/    41/    4d/    59/    65/    71/    7d/    89/    95/    a1/    ad/    b9/    c5/    d1/    dd/    e9/    f5/    pack/
06/    12/    1e/    2a/    36/    42/    4e/    5a/    66/    72/    7e/    8a/    96/    a2/    ae/    ba/    c6/    d2/    de/    ea/    f6/
07/    13/    1f/    2b/    37/    43/    4f/    5b/    67/    73/    7f/    8b/    97/    a3/    af/    bb/    c7/    d3/    df/    eb/    f7/
08/    14/    20/    2c/    38/    44/    50/    5c/    68/    74/    80/    8c/    98/    a4/    b0/    bc/    c8/    d4/    e0/    ec/    f8/
09/    15/    21/    2d/    39/    45/    51/    5d/    69/    75/    81/    8d/    99/    a5/    b1/    bd/    c9/    d5/    e1/    ed/    f9/
0a/    16/    22/    2e/    3a/    46/    52/    5e/    6a/    76/    82/    8e/    9a/    a6/    b2/    be/    ca/    d6/    e2/    ee/    fa/
0b/    17/    23/    2f/    3b/    47/    53/    5f/    6b/    77/    83/    8f/    9b/    a7/    b3/    bf/    cb/    d7/    e3/    ef/    fb/

这里猜测go 1.10使用的应该是与git一类内容摘要算法以及组织存储模式。在前面的build详细输出中，我们找到这一行：

cp $WORK/b001/_pkg_.a /Users/tony/Library/Caches/go-build/7a/7a5671578ed30b125257fd16d0f0b8ceaefd0acc3e44f082ffeecea9f1895499-d # internal

这行命令是将gocmpp包复制到cache下，我们到cache的7a目录下一查究竟：

➜  /Users/tony/Library/Caches/go-build/7a $tree
.
└── 7a5671578ed30b125257fd16d0f0b8ceaefd0acc3e44f082ffeecea9f1895499-d

0 directories, 1 file

我们用nm命令查看一下该文件：

$go tool nm 7a5671578ed30b125257fd16d0f0b8ceaefd0acc3e44f082ffeecea9f1895499-d|more
1c319 T %22%22.(*Client).Connect
   2e279 T %22%22.(*Client).Connect.func1
   3fc22 R %22%22.(*Client).Connect.func1·f
   1c79f T %22%22.(*Client).Disconnect
   1c979 T %22%22.(*Client).RecvAndUnpackPkt
   1c807 T %22%22.(*Client).SendReqPkt
   1c8e2 T %22%22.(*Client).SendRspPkt
   1e417 T %22%22.(*Cmpp2ConnRspPkt).Pack
... ...

这个文件的确就是gocmpp.a文件。通过比对该文件size与go install后的文件size也可以证实这一点：

➜  /Users/tony/Library/Caches/go-build/7a $
-rw-r--r--    1 tony  staff  445856 Feb 15 22:34 7a5671578ed30b125257fd16d0f0b8ceaefd0acc3e44f082ffeecea9f1895499-d

vs.

➜  $GOPATH/pkg/darwin_amd64/github.com/bigwhite $ll
-rw-r--r--  1 tony  staff  445856 Feb 15 23:27 gocmpp.a

也就是说go compiler将编译后的package的.a文件求取摘要值后，将.a文件存储在$GOCACHE下的某个目录中，这个目录名即为摘要值的前两位（比如”7a”），.a文件名字被换成其摘要值，以便后续查找并做比对。

cache目录下还有一个重要文件：log.txt，这个文件是用来记录缓存管理日志的，其内容格式如下：

//log.txt
... ...

1518705271 get 7533a063cd8c37888b19674bf4a4bb7e25fa422041082566530d58538c031516
1518705271 miss b6b9f996fbd14e4fd43f72dc4f9082946cddd0d61d6c6143c88502c8a4001666
1518705271 put b6b9f996fbd14e4fd43f72dc4f9082946cddd0d61d6c6143c88502c8a4001666 7a5671578ed30b125257fd16d0f0b8ceaefd0acc3e44f082ffeecea9f1895499 445856
1518705271 put f5a641ca081a0d2d794b0b54aa9f89014dbb6ff8d14d26543846e1676eca4c21 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 0
1518708456 get 899589360d856265a84825dbeb8d283ca84e12f154eefc12ba84870af13e1f63
1518708456 get 8a7fcd97a5f36bd00ef084856c63e4e2facedce33d19a5b557cc67f219787661

该日志文件更多的用途是帮助Russ Cox对其开发的cache进行调试和问题诊断的。当然，如果您对于cache的机制原理也很精通，那么也可以让log.txt帮你诊断涉及cache的问题。

d) go test with cache

go 1.10版的go test也会维护一个cache，这个cache缓存了go test执行的测试结果。同时在go 1.10中，go test被分为两种执行模式：local directory mode和package list mode，在不同模式下，cache机制的介入是不同的。

local directory mode，即go test以整个当前目录作为隐式参数的执行模式，比如在某个目录下执行”go test”，go test后面不带任何显式的package列表参数（当然可以带着其他命令行flag参数，如-v）。在这种模式下，cache机制不会介入，go test的执行过程与go 1.10版本之前没有两样。还是以gocmpp这个项目为例，我们以local directory mode执行go test：

➜  $GOPATH/src/github.com/bigwhite/gocmpp git:(master) ✗ $go test
PASS
ok      github.com/bigwhite/gocmpp    0.011s

如果缓存机制介入，输出的test结果中会出现cached字样，显然上面的go test执行过程并没有使用test cache。

package list mode，即go test后面显式传入了package列表，比如：go test math、go test .、go test ./…等，在这种模式下，test cache机制会介入。我们连续两次在gocmpp目录下执行go test .：

➜  $GOPATH/src/github.com/bigwhite/gocmpp git:(master) ✗ $go test .
ok      github.com/bigwhite/gocmpp    0.011s
➜  $GOPATH/src/github.com/bigwhite/gocmpp git:(master) ✗ $go test .
ok      github.com/bigwhite/gocmpp    (cached)

如果你此时想进一步看看go test执行的详细输出，你可以会执行go test -v .：

➜  $GOPATH/src/github.com/bigwhite/gocmpp git:(master) ✗ $go test -v .
=== RUN   TestTypeString
--- PASS: TestTypeString (0.00s)
=== RUN   TestCommandIdString
--- PASS: TestCommandIdString (0.00s)
=== RUN   TestOpError
--- PASS: TestOpError (0.00s)
... ...
=== RUN   TestCmppTerminateRspPktPack
--- PASS: TestCmppTerminateRspPktPack (0.00s)
=== RUN   TestCmppTerminateRspUnpack
--- PASS: TestCmppTerminateRspUnpack (0.00s)
PASS
ok      github.com/bigwhite/gocmpp    0.017s

你会发现，这次go test并没有使用cache。如果你再执行一次go test -v .：

➜  $GOPATH/src/github.com/bigwhite/gocmpp git:(master) ✗ $go test -v .
=== RUN   TestTypeString
--- PASS: TestTypeString (0.00s)
=== RUN   TestCommandIdString
--- PASS: TestCommandIdString (0.00s)
=== RUN   TestOpError
--- PASS: TestOpError (0.00s)
... ...
=== RUN   TestCmppTerminateRspPktPack
--- PASS: TestCmppTerminateRspPktPack (0.00s)
=== RUN   TestCmppTerminateRspUnpack
--- PASS: TestCmppTerminateRspUnpack (0.00s)
PASS
ok      github.com/bigwhite/gocmpp    (cached)

test cache又起了作用。似乎cache对于go test .和go test -v .是独立的。没错，release note中给出的go test cache的介入条件如下：

• 本次测试的执行程序以及命令行（及参数）与之前的一次test运行匹配；（这就能解释为何go test -v .没有使用go test .执行的cache了）；
• 上次测试执行时的文件和环境变量在本次没有发生变化；
• 测试结果是成功的；
• 以package list node运行测试；
• go test的命令行参数使用”-cpu, -list, -parallel, -run, -short和 -v”的一个子集时

就像前面我们看到的，cache介入的go test结果不会显示test消耗的时间，而是以(cached)字样替代。

绝大多数Gopher都是喜欢test with cache的，但总有一些情况，cache是不受欢迎的。其实前面的条件已经明确告知gopher们什么条件下test cache是可以不介入的。一个惯用的关闭test cache的方法是使用-count=1：

➜  $GOPATH/src/github.com/bigwhite/gocmpp git:(master) ✗ $go test -count=1  -v .
=== RUN   TestTypeString
--- PASS: TestTypeString (0.00s)
=== RUN   TestCommandIdString
--- PASS: TestCommandIdString (0.00s)
=== RUN   TestOpError
--- PASS: TestOpError (0.00s)
... ...
=== RUN   TestCmppTerminateRspPktPack
--- PASS: TestCmppTerminateRspPktPack (0.00s)
=== RUN   TestCmppTerminateRspUnpack
--- PASS: TestCmppTerminateRspUnpack (0.00s)
PASS
ok      github.com/bigwhite/gocmpp    0.012s

go 1.10中的go test与之前版本还有一个不同，那就是go test在真正执行test前会自动对被测试的包执行go vet，但这个vet只会识别那些最为明显的问题。并且一旦发现问题，go test将会视这些问题与build error同级别，阻断test的执行，并让其出现在test failure中。当然gopher可以通过go test -vet=off关闭这个前置于测试的vet检查。

4. pprof

go tool pprof做了一个较大的改变：增加了Web UI，以后可以和go trace一起通过图形化的方法对Go程序进行调优了。可视化的pprof使用起来十分简单，我们以gocmpp为例，试用一下go 1.10的pprof，首先我们生成cpu profile文件：

➜  $GOPATH/src/github.com/bigwhite/gocmpp git:(master) ✗ $go test -run=^$ -bench=. -cpuprofile=profile.out
goos: darwin
goarch: amd64
pkg: github.com/bigwhite/gocmpp
BenchmarkRecvAndUnpackPkt-4                1000000          1534 ns/op
BenchmarkCmppConnReqPktPack-4              1000000          1398 ns/op
BenchmarkCmppConnReqPktUnpack-4            3000000           450 ns/op
BenchmarkCmpp2DeliverReqPktPack-4          1000000          1156 ns/op
BenchmarkCmpp2DeliverReqPktUnpack-4        3000000           567 ns/op
BenchmarkCmpp3DeliverReqPktPack-4          1000000          1173 ns/op
BenchmarkCmpp3DeliverReqPktUnpack-4        3000000           465 ns/op
BenchmarkCmpp2FwdReqPktPack-4              1000000          2079 ns/op
BenchmarkCmpp2FwdReqPktUnpack-4            1000000          1276 ns/op
BenchmarkCmpp3FwdReqPktPack-4              1000000          2507 ns/op
BenchmarkCmpp3FwdReqPktUnpack-4            1000000          1286 ns/op
BenchmarkCmpp2SubmitReqPktPack-4           1000000          1845 ns/op
BenchmarkCmpp2SubmitReqPktUnpack-4         1000000          1251 ns/op
BenchmarkCmpp3SubmitReqPktPack-4           1000000          1863 ns/op
BenchmarkCmpp3SubmitReqPktUnpack-4         2000000           656 ns/op
PASS
ok      github.com/bigwhite/gocmpp    26.621s

启动pprof web ui：

$go tool pprof -http=:8080 profile.out

pprof会自动打开默认浏览器，进入下面页面：

在view菜单中，我们可以看到”top”、”graph”、”peek”、”source”和”disassemble”几个选项，这些选项可以帮助你在各种视图间切换，默认初始为graph view。不过目前view菜单中并没有”Flame Graph(火焰图)”选项，要想使用Flame Graph，我们需要使用原生的pprof工具，该工具可通过go get -u github.com/google/pprof获取，install后原生pprof将出现在$GOROOT/bin下面。

使用原生pprof启动Web UI：

$pprof -http=:8080 profile.out

原生pprof同样会自动打开浏览器，进入下面页面：

原生的pprof的web ui看起来比go 1.10 tool中的pprof更为精致，且最大的不同在于VIEW菜单下出现了”Flame Graph”菜单项！我们点击该菜单项，一幅Flame Graph便呈现在眼前：

关于如何做火焰图分析不是这里的主要任务，请各位Gopher自行脑补。更多关于Go性能调优问题，可以参考Go官方提供的诊断手册。

四、标准库

和之前的每次Go版本发布一样，标准库的改变是多且细碎的，这里不能一一举例说明。并且很多涉“专业领域”的包，比如加解密，需要一定专业深度，因此这里仅列举几个“通用”的变化^0^。

1、strings.Builder

strings包增加一个新的类型：Builder，用于在“拼字符串”场景中替代bytes.Buffer，由于使用了一些unsafe包的黑科技，在用户调用Builder.String()返回最终拼成的字符串时，避免了一些重复的、不必要的内存copy，提升了处理性能，优化了内存分配。我们用一个demo来看看这种场景下Builder的优势：

//go1.10-examples/stdlib/stringsbuilder/builer.go
package builder

import (
    "bytes"
    "strings"
)

type BuilderByBytesBuffer struct {
    b bytes.Buffer
}
func (b *BuilderByBytesBuffer) WriteString(s string) error {
    _, err := b.b.WriteString(s)
    return err
}
func (b *BuilderByBytesBuffer) String() string{
    return b.b.String()
}

type BuilderByStringsBuilder struct {
    b strings.Builder
}

func (b *BuilderByStringsBuilder) WriteString(s string) error {
    _, err := b.b.WriteString(s)
    return err
}
func (b *BuilderByStringsBuilder) String() string{
    return b.b.String()
}

针对上面代码中的BuilderByBytesBuffer和BuilderByStringsBuilder进行Benchmark的Test源文件如下：

//go1.10-examples/stdlib/stringsbuilder/builer_test.go
package builder

import "testing"

func BenchmarkBuildStringWithBytesBuffer(b *testing.B) {
    var builder BuilderByBytesBuffer

    for i := 0; i < b.N; i++ {
        builder.WriteString("Hello, ")
        builder.WriteString("Go")
        builder.WriteString("-1.10")
        _ = builder.String()
    }

}
func BenchmarkBuildStringWithStringsBuilder(b *testing.B) {

    var builder BuilderByStringsBuilder

    for i := 0; i < b.N; i++ {
        builder.WriteString("Hello, ")
        builder.WriteString("Go")
        builder.WriteString("-1.10")
        _ = builder.String()
    }
}

执行该Benchmark，查看结果：

$go test -bench . -benchmem
goos: darwin
goarch: amd64
pkg: github.com/bigwhite/experiments/go1.10-examples/stdlib/stringsbuilder
BenchmarkBuildStringWithBytesBuffer-4            100000        108471 ns/op      704073 B/op           1 allocs/op
BenchmarkBuildStringWithStringsBuilder-4       20000000           122 ns/op          80 B/op           0 allocs/op
PASS
ok      github.com/bigwhite/experiments/go1.10-examples/stdlib/stringsbuilder    13.616s

可以看到StringsBuilder在处理速度和分配优化上都全面强于bytes.Buffer，真实的差距就在Builder.String这个方法上。

2、bytes包

bytes包的几个方法Fields, FieldsFunc, Split和SplitAfter在底层实现上有变化，使得外部展现的行为有所变化，我们通过一个例子直观的感受一下：

// go1.10-examples/stdlib/bytessplit/main.go
package main

import (
    "bytes"
    "fmt"
)

// 来自github.com/campoy/gotalks/blob/master/go1.10/bytes/fields.go
func desc(b []byte) string {
    return fmt.Sprintf("len: %2d | cap: %2d | %q\n", len(b), cap(b), b)
}

func main() {
    text := []byte("Hello, Go1.10 is coming!")
    fmt.Printf("text:  %s", desc(text))

    subslices := bytes.Split(text, []byte(" "))
    fmt.Printf("subslice 0:  %s", desc(subslices[0]))
    fmt.Printf("subslice 1:  %s", desc(subslices[1]))
    fmt.Printf("subslice 2:  %s", desc(subslices[2]))
    fmt.Printf("subslice 3:  %s", desc(subslices[3]))
}

我们先用Go 1.9.2编译运行一下该demo:

$go run main.go
text:  len: 24 | cap: 32 | "Hello, Go1.10 is coming!"
subslice 0:  len:  6 | cap: 32 | "Hello,"
subslice 1:  len:  6 | cap: 25 | "Go1.10"
subslice 2:  len:  2 | cap: 18 | "is"
subslice 3:  len:  7 | cap: 15 | "coming!"

我们再用go 1.10rc2运行一下该demo：

$go run main.go
text:  len: 24 | cap: 32 | "Hello, Go1.10 is coming!"
subslice 0:  len:  6 | cap:  6 | "Hello,"
subslice 1:  len:  6 | cap:  6 | "Go1.10"
subslice 2:  len:  2 | cap:  2 | "is"
subslice 3:  len:  7 | cap: 15 | "coming!"

对比两次输出结果中cap那一列，你会发现go 1.10输出的结果中的每个subslice(除了最后一个)的len与cap值都是相等的，而不是将原slice剩下所有cap都作为subslice的cap。这个行为的改变是出于安全的考虑，防止共享一个underlying slice的各个subslice的修改对相邻的subslice造成影响，因此限制它们的capacity。

在Fields, FieldsFunc, Split和SplitAfter这几个方法的具体实现上，Go 1.10使用了我们平时并不经常使用的”Full slice expression“，即：a[low, high, max]来指定subslice的cap。

五、性能

对于静态编译类型语言Go来说，性能也一直是其重点关注的设计目标，这两年来发布的Go版本，几乎每个都给Gopher们带来惊喜。谈到Go性能，Gopher们一般关心的有如下这么几个方面：

1、编译性能

Go 1.10的编译性能正如我们前面所说的那样，最大的改变在于cache机制的实现。事实证明cache机制的使用在日常开发过程中，会很大程度上提升你的工作效率，越是规模较大的项目越是如此。

2、目标代码的性能

这些年Go team在不断优化编译器生成的目标代码的性能，比如在Go 1.7版本中引入ssa后端。Go 1.10延续着对目标代码生成的进一步优化，虽说动作远不如引入ssa这么大。

3、GC性能

GC的性能一直是广大Gopher密切关注的事情，Go 1.10在减少内存分配延迟以及GC运行时的负担两个方面做了许多工作，但从整体上来看，Go 1.10并没有引入传说中的TOC(Transaction Oritented Collector)，因此宏观上来看，GC变化不是很大。Twitter上的GC性能测试“专家”Brian Hatfield在对Go 1.10rc1的GC测试后，也表示与Go 1.9相比，变化不是很显著。

六、小结

Go 1.10版本又是一个Go team和Gopher社区共同努力的结果，让全世界Gopher都对Go保持着极大的热情和期望。当然Go 1.10中的变化还有许多许多，诸如：

• 对Unicode规范的支持升级到10.0；
• 在不同的平台上，Assembler支持更多高性能的指令；
• plugin支持darwin/amd64等；
• gofmt、go doc在输出格式上进一步优化和提升gopher开发者体验；
• cgo支持直接传递go string到C代码中;
  … …

很多很多！这里限于篇幅原因，不能一一详解了。通读一遍Go 1.10 Release Note是每个Gopher都应该做的。

以上验证在mac OS X, go 1.10rc2上测试，demo源码可以在这里下载。

七、参考资料

• Go 1.10 Release Notes
• The State of Go by campoy
• Go 1.10
• pprof user interface
• cmd/go content-based staleness submitted
• Go 1.10 cmd/go: build cache, test cache, go install, go vet, test vet

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

我的联系方式：

微博：http://weibo.com/bigwhite20xx
微信公众号：iamtonybai
博客：tonybai.com
github: https://github.com/bigwhite

微信赞赏：

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