fix typo

ch1/ch1-1.md

@@ -2,7 +2,7 @@
 
 Go语言从2007年开始设计，2009年底正式开源，而第一个正式的版本Go1则是在2012年上半年发布。Go1的语法变迁主要从Go第一个正式版本开始，Go1是Go语言官方对整个社区的承诺：Go1之后的版本将保证源代码层面兼容。
 
-从Go1的发布日志可以发现，Go1对语言和标准库做了严谨的梳理和完善，Go1的重大变化主要集中在语言和标准库部分。其中语言部分最大的变化是将原先的`os.Error`接口用内置的`error`接口类型替代、内置函数引入了`close`函数用户管道的关闭操作。此外，还对加强了`init`、`append`内置函数；增强了复合类型字面值的支持；针对Unicode字符增加了`rune`别名；改善了对map的遍历和删除元素操作；改进了影子返回值的报警提示；复制结构体时涵盖未导出的成员；明确了哪些类型可以进行相等性测试。同时对每个标准库的路径和功能进行详细的设计和完善。
+从Go1的发布日志可以发现，Go1对语言和标准库做了严谨的梳理和完善，Go1的重大变化主要集中在语言和标准库部分。其中语言部分最大的变化是将原先的`os.Error`接口用内置的`error`接口类型替代、内置函数引入了`close`函数用于管道的关闭操作。此外，还对加强了`init`、`append`内置函数；增强了复合类型字面值的支持；针对Unicode字符增加了`rune`别名；改善了对map的遍历和删除元素操作；改进了影子返回值的报警提示；复制结构体时涵盖未导出的成员；明确了哪些类型可以进行相等性测试。同时对每个标准库的路径和功能进行详细的设计和完善。
 
-经过多年的发展和普及，大家已经对Go1语言和标准库已经耳熟能详，对变更的细节就不详细展开了。但正是这次梳理工作才奠定了Go1之后高速发展的十年。
+经过多年的发展和普及，大家已经对Go1语言和标准库耳熟能详，对变更的细节就不详细展开了。但正是这次梳理工作才奠定了Go1之后高速发展的十年。
 

ch1/ch1-2.md

@@ -68,7 +68,7 @@ for range times {
 }
 ```
 
-其中`times`对应一个`[5][0]int`类型的数组，虽然第一维数组有长度，但是数组的元素`[0]int大小`是`0`，因此整个数组占用的内存大小依然是`0`。没有付出额外的内存代价，我们就通过`for range`方式实现了`times`次快速迭代。
+其中`times`对应一个`[5][0]int`类型的数组，虽然第一维数组有长度，但是数组的元素`[0]int`大小是`0`，因此整个数组占用的内存大小依然是`0`。没有付出额外的内存代价，我们就通过`for range`方式实现了`times`次快速迭代。
 
 
 ## 1.2.4 Go1.7（2016年8月）
@@ -153,7 +153,7 @@ type MakeReaderC interface {
 }
 ```
 
-比较神奇的是`MakeReaderC`和`MakeReaderB`接口可能是等价的，因为它定义的方法名和签名都是相同的。MakeReader方法返回的都是一个匿名的`interface { Read(p []byte) (n int, err error) }`接口类型。而Go语言中，所有的结构相同的匿名类型其实是同一个类型。
+比较神奇的是`MakeReaderC`和`MakeReaderB`接口可能是等价的，因为它定义的方法名和签名都是相同的。`MakeReader`方法返回的都是一个匿名的`interface { Read(p []byte) (n int, err error) }`接口类型。而Go语言中，所有的结构相同的匿名类型其实是同一个类型。
 
 如果通过类型别名从匿名接口构造接口，就可以避免新定义的不同接口类型对接口的方法签名造成影响。
 

ch1/ch1-3.md

@@ -6,7 +6,7 @@
 
 在Go语言的发展史中，2018年注定是一个重要的时间点，因为在2018年8月正式发布了Go1.11。Go1.11语言部分虽然没有变化，但是带来了3个重量级的更新：一是`amd64`平台完全支持`AVX512`高性能的指令集；二是Go1.11开始支持模块化的特性；三是Go语言开始WebAssembly平台。这几个个改进将成为后Go1时代最大的亮点。
 
-首先`AVX512`高性能的指令集可以让Go语言榨干CPU性能全部的，为Go2进军运算密集型应用做好准备（如果对Go汇编语言感兴趣，可以参考作者的[《Go语言高级编程》](https://github.com/chai2010/advanced-go-programming-book)中汇编语言相关的章节）。而模块是管理任何大型工程必备的工具，但是Go语言发布十年来一直缺乏官方的模块化工具。模块化的特性将彻底解决大型Go语言工程的管理问题，至此Go1除了缺少泛型等特性已经近乎完美。最后，WebAssembly作为一个Web汇编语言和虚拟机标准，Go语言可能为Web开发打开一个崭新的领域。
+首先`AVX512`高性能的指令集可以让Go语言榨干CPU的全部性能，为Go2进军运算密集型应用做好准备（如果对Go汇编语言感兴趣，可以参考作者的[《Go语言高级编程》](https://github.com/chai2010/advanced-go-programming-book)中汇编语言相关的章节）。而模块是管理任何大型工程必备的工具，但是Go语言发布十年来一直缺乏官方的模块化工具。模块化的特性将彻底解决大型Go语言工程的管理问题，至此Go1除了缺少泛型等特性已经近乎完美。最后，WebAssembly作为一个Web汇编语言和虚拟机标准，Go语言可能为Web开发打开一个崭新的领域。
 
 关于模块和WebAssembly都是较大的主题，它们目前都还是作为实验特性，希望在后序版本中逐步完成。在本书将有专门的章节讨论模块和WebAssembly相关的技术。
 

ch1/ch1-4.md

@@ -1,5 +1,5 @@
 # 1.4 Go2诞生
 
-在2018年官方已经发布了Go2的设计草案，其中包含了令人惊喜的范型和错误等诸多改进，在后Go1时代过去之后将是新兴的Go2时代。需要说明的是，Go2的诞生并不表示Go1被抛弃！如何避免Py3k的笑话正是Go2第一要考虑的问题，因此才会有Go1.11到Go2逐步过段的阶段。而Go语言官方也已经通过博文承诺Go2将保持对Go1软件资产的最大兼容，鉴于Go1诺言被忠实地执行的参考，我们有理由相信Go2会处理好Go1资产的兼容性问题。
+在2018年官方已经发布了Go2的设计草案，其中包含了令人惊喜的泛型和错误等诸多改进，在后Go1时代过去之后将是新兴的Go2时代。需要说明的是，Go2的诞生并不表示Go1被抛弃！如何避免Py3k的笑话正是Go2第一要考虑的问题，因此才会有Go1.11到Go2逐步过段的阶段。而Go语言官方也已经通过博文承诺Go2将保持对Go1软件资产的最大兼容，鉴于Go1诺言被忠实地执行的参考，我们有理由相信Go2会处理好Go1资产的兼容性问题。
 
-大约在2012年前后，作者曾乐观估计Go2将在2020年前后到来，并可能带来大家期盼已久的范型特性。作者在此预测Go2将在2020年正式进入开发流程，并在2022年前后进入工业生产环境使用，而Go1将在2030年前后逐渐退出历史。为了在Go2正式到来时轻装上阵，我们需要提前把握Go语言的发展动向，而本书正是为此目标准备。
+大约在2012年前后，作者曾乐观估计Go2将在2020年前后到来，并可能带来大家期盼已久的泛型特性。作者在此预测Go2将在2020年正式进入开发流程，并在2022年前后进入工业生产环境使用，而Go1将在2030年前后逐渐退出历史。为了在Go2正式到来时轻装上阵，我们需要提前把握Go语言的发展动向，而本书正是为此目标准备。

ch2/ch2-1.md

@@ -43,16 +43,16 @@ include $(GOROOT)/src/Make.pkg
 
 ## 2.1.3 `GOPATH`特性的扩展
 
-扩展`GOPATH`的目标都是为了更方便管理包。Go语言的包有三种类型：首先是叶子包，此类包最多依赖标准库，不依赖第三方包；首先是`main`包表示一个应用，它不能被其它包导入（单元测试除外）；最后是普通的依赖第三方包的非`main`包。比较特殊的`main`包同时也是一个叶子包。
+扩展`GOPATH`的目标都是为了更方便管理包。Go语言的包有三种类型：首先是叶子包，此类包最多依赖标准库，不依赖第三方包；其次是`main`包表示一个应用，它不能被其它包导入（单元测试除外）；最后是普通的依赖第三方包的非`main`包。比较特殊的`main`包同时也是一个叶子包。
 
-叶子包自身很少会遇到版本管理问题，因为不会遇到因为依赖第三方包产生的各种问题，因此叶子包的开发者很少关注版本管理的问题。稍微复杂一点的是`main`包，`main`包是包依赖中的根包。`main`包不担心被其它包依赖，因此它其实是可以通过一个独占的`GOPATH`来维护所有依赖的第三方包的。最复杂的是既不是`main`包，也不是叶子包的普通，因为普通包需要管理其依赖的第三方包，同时一般又不能单独管理`GOAPTH`。在vendor出现之前的版本管理实践中，普通包的版本比较简陋，很多普通包甚至都没有版本管理，只有`master`一个最新版本。
+叶子包自身很少会遇到版本管理问题，因为不会遇到因为依赖第三方包产生的各种问题，因此叶子包的开发者很少关注版本管理的问题。稍微复杂一点的是`main`包，`main`包是包依赖中的根包。`main`包不担心被其它包依赖，因此它其实是可以通过一个独占的`GOPATH`来维护所有依赖的第三方包的。最复杂的是既不是`main`包，也不是普通的叶子包，因为普通包需要管理其依赖的第三方包，同时一般又不能单独管理`GOAPTH`。在vendor出现之前的版本管理实践中，普通包的版本比较简陋，很多普通包甚至都没有版本管理，只有`master`一个最新版本。
 
-`GOPATH`的扩展主要分为横向和纵向两个方向。横向就是同时并列维护多个GOPATH目录，通过手工方式调整其中某些目录来实现目录中包版本切换的目的。纵向扩展一般在管理main包对应的应用程序中使用，通过在包内部创建临时的GOPATH子目录，在GOPATH子目录中包含全部第三方依赖的拷贝来实现外部依赖包版本的管理。
+`GOPATH`的扩展主要分为横向和纵向两个方向。横向就是同时并列维护多个`GOPATH`目录，通过手工方式调整其中某些目录来实现目录中包版本切换的目的。纵向扩展一般在管理`main`包对应的应用程序中使用，通过在包内部创建临时的`GOPATH`子目录，在`GOPATH`子目录中包含全部第三方依赖的拷贝来实现外部依赖包版本的管理。
 
-社区中早期出现的Godeps工具就是通过在当前目录下创建`Godeps/_workspace`子目录来管理维护依赖的第三方包的版本。Godeps的实践成果最终被吸收到来Go语言中，通过vendor机制实现来main包的依赖管理（不是版本管理）。但是最终vendor机制也带来来各种问题（稍后的章节会讨论），最终官方完全重新设计了模块化的特性。
+社区中早期出现的Godeps工具就是通过在当前目录下创建`Godeps/_workspace`子目录来管理维护依赖的第三方包的版本。Godeps的实践成果最终被吸收到来Go语言中，通过vendor机制实现来`main`包的依赖管理（不是版本管理）。但是最终vendor机制也带来了各种问题（稍后的章节会讨论），最终官方完全重新设计了模块化的特性。
 
 ## 2.1.4 模块化之后的包目录路径
 
 通过vendor机制来实现版本管理的尝试虽然失败了，但是通过横向扩展`GOPATH`的来维护同一个包的不同版本的思路却在模块中复活了。模块化通过重新组织目录结构，实现了同时管理同一个包的不同版本需求。
 
-比如之前`$(GOPATH)/src/github.com/chai2010/pbgo`包的`1.0.0`版本，在模块化之后将对应`$(HOME)/go/pkg/mod/github.com/chai2010/pbgo@1.0.0`。模块化通过`$(HOME)/go/pkg/mod`目录管理第三方的依赖包，同时通过`pkg@x.y.z`的版本后缀来区分同一个包的不同版本。这其实和多个GOPATH并列存放的思路是类似，不过模块化对多版本支持的更加完美。
+比如之前`$(GOPATH)/src/github.com/chai2010/pbgo`包的`1.0.0`版本，在模块化之后将对应`$(HOME)/go/pkg/mod/github.com/chai2010/pbgo@1.0.0`。模块化通过`$(HOME)/go/pkg/mod`目录管理第三方的依赖包，同时通过`pkg@x.y.z`的版本后缀来区分同一个包的不同版本。这其实和多个`GOPATH`并列存放的思路是类似，不过模块化对多版本支持的更加完美。