为放弃与 Go+ 开发者及行业从业者的亲密沟通，独特促成、交换 Go+ 的迭代倒退，Go+ 开发团队策动了「Go+ 公开课」系列直播课程。「Go+ 公开课」将以每周一期的节奏陆续推出精彩的干货分享，欢送 Go+ 开发者、爱好者继续关注！
第一期：Go+ v1.x 的设计与实现（点击左侧文字链可查看内容回顾）
第二期：import 过程与 Go+ 的模块治理（主讲人：七牛云 CEO、Go+ 语言发明人 许式伟）
本文为第二期直播内容整顿。
咱们接下来对外输入的 Go+ 内容建设次要蕴含两个局部：
第一类面向更为宽泛的 Go+ 使用者，Go+ 的官网 GitHub 中有相干的个性介绍，以及性能开发的操作介绍。咱们也在继续整顿相干根底文档以及材料，供开发者应用、学习。
第二类也就是相似「Go+ v1.x 设计」系列的内容，是面向心愿了解这门语言背地的原理，心愿更进一步参加 Go+ 开发、成为 Go+ 贡献者、为社区深度奉献价值的社区贡献者，以及局部心愿取得深度体验的用户。
我有一个观点，只有深度了解事物背地原理后，能力更好的应用它。因而，「Go+ v1.x 设计」系列的内容更多会从 Inside Go+ 的视角进行分享。第一期中我分享来了 Go+ 的宏观架构，本期会联合具体的性能开发，为大家介绍 Go+ 如何实现具体的性能。
本期的分享内容是「import 过程与 Go+ 的模块治理」。之所以第二期抉择这一话题，是因为 import 过程与模块治理属于绝对宏观的过程，与具体分享 Go+ 有哪些语法实现相比，了解它更加重要一些，更有助于大家了解 Go+。
本期的分享次要分为两局部：
Go+ 的 import 过程
Go+ 模块治理
一. Go+ 的 import 过程
其实 Go+ import 的语法与 Go 基本上没有太大的区别，Go 的 import 语法内容绝对较多，咱们把它具体开展的话能够有下图这些内容。
在这个图中，蕴含了 import Go 的规范库、import 一个用户自定义包，还有 import 一个 Go+ 规范库比方 import “gop/ast”。而红色的 import lacal package 局部，通过相对路径来引入包的语法格局，因为工程中很少会应用这一性能，所以 Go+ 临时还没有实现。
还有一种写法，是给 import 的包定一个别名。有两个非凡的别名：“_”和“.”，其中“_”应用较为广泛，而“.”则也是官网不举荐应用的写法。
有了语法后，下一步要理解的便应该是 token&scanner 和 ast&parser。因为其余部分都绝对比拟一般，咱们明天次要来重点探讨下 import 一个包的 ast，也就是形象语法树。
这个形象语法树比拟深，但其实内容比拟根底。最顶层是包（Package），包上面是文件列表，再上面一层是全局申明列表。全局申明分为两类：一类叫函数申明（FuncDecl），另一类叫通用申明（GenDecl）。
通用申明看起来比拟形象，次要是蕴含 Import、Type、Var、Const 四类申明。通用申明与函数申明的区别在于，函数申明一次只能申明一个函数，而在通用申明中，你能够同时 import 多个包，也能够一次定义多个 Type 类型，尽管这种做法不太常见，然而可行的。同时申明多个变量或常量则应用较为广泛。
在通用申明下蕴含所谓的规格列表（Specs）。规格也是一个形象的设定，明天咱们关注的 ImportSpec，它代表导入了一个包。ImportSpec 上面则是包的别名（Name），包的门路（Path）。
以上就是 Import 包相干的形象语法树了。
有了形象语法树后，便是对形象语法树进行编译。咱们在第 1 期内容中介绍过，编译过程最次要做的事件，就是将 Go+ 的形象语法树转为对 gox DOM Writer 组件的函数调用。在 gox 中，和 import 一个包相干的 DOM Writer 函数有以下几个：
第一个是在 Package 上面有一个 Import 函数，调用它会失去一个 PkgRef 实例。在 PkgRef 类型中有一个最重要的变量是 Types *types.Package，它外面蕴含了包中所有符号的信息。
PkgRef 类有两个比拟重要的办法。一个是 Ref，也就是援用某一个符号，传入符号名字，失去符号的援用；第二个是 MarkForceUsed，也就是强制 import 一个包。
在 gox 中 import 一个包是很聪慧的。如果 import 包后没有应用，在生成的代码中不会体现对该 package 的援用。这相似很多 Go IDE，如果 import 了没有应用过的包，便会主动进行删除这个援用。
要理解 gox DOMWriter 的具体应用形式，咱们看一个具体的例子：
import “fmt”
func main(){
fmt.Println(“Hello world”)
}
这里咱们假如要写一个 Hello world。首先咱们 import fmt 包，而后通过 fmt.PrintIn 输出“Hello world”。这段代码特地简略。
对编译器来说，它会产生以下对 gox 的调用序列：
第一步是 NewPackage。这里咱们假如要创立的是一个 main 包，咱们失去了 main 包的 package 实例，赋值给 pkg 变量。
第二步是调用 pkg.Import，这句话提早加载了 fmt 包，并赋值给 fmt 变量。
接下来咱们再通过 NewFunc 定义了 main 函数。在上一讲咱们咱们用 NewClosure 创立了一个闭包。闭包是非凡的 Func，它没用函数名。NewClosure 只有三个参数：输出、输入和一个代表是否反对可变参数的布尔变量，而 NewFunc 则比 NewClosure 会额定多两个参数，也就是下面的前两个参数：nil 和 “main”。第一个参数是「reciever」，相似其余语言的 this 指针，main 函数没用 receiver，所以为 nil。第二个就比拟好了解了，是函数的名字。
NewFunc 后，就调用 BodyStart 开始实现函数体。在下面这个例子中，函数体就是一个函数调用。在上一讲中咱们介绍过，在 gox 中咱们通过类逆波兰表达式的形式来写代码，也就是先参数列表，再指令。函数调用的指令是 Call。所以这个函数调用的程序是先传函数地址 fmt.Ref(“Println”)，再参数 “Hello world”，而后才是函数调用指令 Call。因为这是带有 1 个参数的函数调用，所以是 Call(1)。最初咱们调用 End 完结函数体。
通过这段代码，咱们能够看到 gox DOM Writer 整体的代码逻辑是十分直观的。只有了解了逆波兰表达式，整个逻辑就非常容易了解。
后面咱们曾经提过，在 import 的过程，gox DOM Writer 会波及到三个函数：
(Package).Import(pkgPath string)PkgRef
(*PkgRef).Ref(name string) Ref
(*PkgRef).MarkForceUsed()
咱们接下来对他们一一具体开展来介绍。
其中，(*Package).Import 函数最重要的一点，这一点后面咱们也提过，在于 import 过程是提早加载的，如果包没有被援用，那么这个 import 便什么都不会产生。
(PkgRef).Ref 函数则会进行判断，如果包还没有被加载的状况下，就会去真正进行包的加载；如果曾经加载，便间接查找相干的符号信息（lookup by name）。因为提早加载的起因，(PkgRef).Ref 可能导致多个包会一起被加载，这很失常。而且从性能优化的角度，咱们激励多包，甚至将所有的包，一起进行加载。
(*PkgRef).MarkForceUsed 代表强制加载一个包。它对应于 Go 语言中 import _ “pkgPath” 这个语法。这种状况尽管 pkgPath import 后没有被应用，然而依然心愿去加载这个包，这时就能够通过调用 MarkForceUsed 来实现强制加载的能力。
在 Go 语言中，import _ “pkgPath” 个别在插件机制中呈现的比拟多。在 Go 规范库中最典型的插件机制是 image 模块。因为要反对的图片格式很多，很难预知须要反对哪些类型的图片。所以在 Go 语言中图片的 encode 和 decode 都基于插件机制，让 image 的零碎更加凋谢。
后面咱们分享了 Import 语法、它对应的形象语法树，编译器和 gox 的调用序列以及 gox 相干函数的介绍。整体来说，import 只是从应用或者整体构造了解的角度来说还是比较简单的。但实际上它外部产生的事件是很简单的。
接下来咱们就来具体介绍下 gox 在 import 包的加载过程中到底产生了什么，以及为什么咱们激励多包同时加载。
实际上 gox import 包的过程中，加载包的代码并不是 gox 本人写的，而是调用了 Go Team 写的一个扩大库 —— golang.org/x/tools/go/package，这个包中有个 Load 函数，能够实现同时加载多个包。
func Load(cfg Config, patterns …string) ([]Package, error)
Load 函数中的 patterns 是要加载的 pkgPath 列表，之所以叫 patterns 是因为它反对用 “…” 表白包的通配符（这和所有 go tools 统一，go install、go build 等也反对包的通配符）。例如 “go/…” 示意所有 “go/” 结尾的 Go 规范库中的包，包含 “go/ast”、”go/token”、”go/parser” 等等。
之所以要反对多个包同时加载，是因为不同包依赖的根底包大同小异，加载过程中有很多反复的工作量，而以后 packages.Load 函数没有缓存机制，速度会很慢。咱们以 fmt 包为例。fmt 依赖于 9 个根底包，加上本身须要加载 10 个包，如果同时加载另一个包比方 os 包，它和 fmt 有大量反复加载的根底包，如果同时加载 os 和 fmt 就无需反复加载这些包，从而加载速度大幅晋升。
Load 的后果是一个 Package 列表，列表中有两个重要的变量：
Imports map[string]*Package：通过这个变量能够构建包与包间的依赖关系树；
Types types.Package：依赖包的外围信息，通过该变量能够构建出 gox.PkgRef 实例。
然而，我集体认为，package.Load 函数在设计上有比拟大的问题。这次要体现在：
- 反复加载的开销
尽管尽量单次 Packages.Load 加载多个包能够肯定水平上防止反复加载的问题，但如上所述，屡次 Packages.Load 调用之间没有进行优化，会导致很多反复加载的开销。
咱们举个例子。假如咱们将 Load(nil,”go/token”); Load(nil,”go/ast”); Load(nil,”go/parser”) 合并为 Load(nil,”go/token”,”go/ast”.”go/parser”)，那么后者的加载工夫根本只有靠近前者的三分之一，多一次调用就是多一次的开销。
而且，packages.Load 的加载工夫甚至到了秒级，很慢很慢。因而，这是一个须要解决的大问题。
- 屡次 packages.Load 导致雷同的包有多份实例
每次 packages.Load 产生的 *types.Package 实例是独立的，屡次调用会导致同一个包存在多个实例。这个问题导致的后果是，咱们不能简略用 T1 == T2 来判断是否是同一类型。这很反直觉。而因为不同的包间存在依赖关系，这种反直觉最终会产生很奇怪的后果。
例如将 Load(nil,”go/token”); Load(nil,”go/ast”); Load(nil,”go/parser”) 离开调用，那么 parser.ParseDir 一类的第一个参数类型为 token.FileSet，它和独自调用 Load(nil,”go/token”) 结构出的 token.FileSet 类型实例，尽管名字截然不同，然而咱们真去做类型匹配却会失败。
那么，怎么解决这两个问题？在 Go+ 中，咱们确实做了相应的解决方案。
首先，为解决加载慢的问题，Go+ 引入 package.Load 的缓存。只有有一个包在加载中被发现未缓存，便会调用 package.Load 进行加载，加载完后便会被缓存下来，下次调用便无需反复进行加载。
而为解决雷同包产生多份多份实例的问题，Go+ 对 package.Load 的后果进行了一次 dedup 操作，也就是去反复化。具体的流程是，咱们对第二次 package.Load 的后果进行扫描和重构，确保雷同类型只有一个实例（具体代码可查看：gox/dedup.go）。
这是一种补丁式的改法，更彻底的改法是批改 package.Load 自身，让屡次 Load 间能够共享依赖包。这个形式我认为更加迷信，但基于尽量不调整第三方包的准则，Go+ 目前采纳了 dedup 这样的「后处理」过程来解决。
咱们重点聊一下 packages.Load 缓存的机制。
首先咱们简略看一下缓存过程自身，这很根底。它大略的逻辑是，在 package.Load 前先查问要加载的包是否曾经缓存过，如果缓存过，间接返回后果；如果没有缓存过，先调用 package.Load，而后 dedup 解决包反复实例的问题，而后再保留到缓存中。
这个过程详见 gox/import.go 的 func(*LoadPkgCached)load 函数。
当然这个还不够。在程序退出时，咱们还要对所有依赖包的缓存进行长久化。长久化的逻辑，是先将它们序列化成 json，而后再进行 zip 的压缩。这个 zip 压缩过程中十分重要，如果不压缩整个的缓存会比拟大。最初压缩后咱们将缓存保留为 $ModRoot/.gop/gop.cache 文件。
如果大家理解 Go 语言的工具链就会晓得 Go 自身也有做相似 package.Load 的缓存，只不过它的缓存是全局的，而 Go+ 不同，咱们的缓存是模块级的。在每一个编译的模块根目录下会设有暗藏目录 .gop，其中保留的便是缓存文件。
具体缓存长久化的代码可详见：gox/persist.go。
当然大家都晓得，缓存有缓存的问题。所有缓存要思考的一个重点问题，就是缓存的更新。对于这个问题咱们分为几类状况来看。
首先，如果依赖包是 Go 规范库，因为本地的属性以及不太会有人批改 Go 的规范库，咱们可认为这种状况下，缓存是不会变动的。
如果依赖包不是 Go 规范库，那么就须要计算依赖包的指纹。如果指纹发生变化，则认为依赖包发生变化。如何计算指纹？它蕴含两种状况：
- 如果依赖包属于本 Module 内的（代码在 $ModRoot 下），那么咱们须要枚举 files（文件列表）后依据每个文件的最初更新工夫计算指纹。算法详见：gox/import.go 的 func calcFingerp 函数；
- 如果依赖包不属于本 Module 内的（此性能暂未实现），那么须要读 go.mod 文件来查看该依赖包的版本（tag），若两次 packages.Load 的版本没变则认为包没有变动。当然一个非凡的状况是咱们还要思考 replace 情景，如果某个包被 replace 为本地代码，则视同该依赖包属于本 Module 内的依赖解决。
当然，这个暂未实现的性能心愿大家能够尝试进行实现。目前状况下，如果你发现 gop 编译时依赖包的信息过期了，长期的解决计划是手工删除 gop cache 文件（删除指令：rm $ModRoot/.gop/gop.cache）。
二. Go+ 模块治理
对于 Go+ 模块治理有个很根底但外围的问题 —— 模块（Module）是什么？
首先，模块不同于包（Package），一个模块通常蕴含一个或多个包。我本人给模块简略做的定义如下：
模块是代码公布的单元
模块是代码版本治理的单元
这两个定义实质是已知的。情理很天然，有公布才有版本治理。版本治理就是针对公布单元而进行的。
对于 Go+ 模块治理这部分的内容，咱们也分为两局部：
如何 import 一个 Go+ 的包
如何治理 Go+ 模块
- 如何 import 一个 Go+ 的包
大家思考一下，在 gox import 过程中，传给 packages.Load 的 pkgPath 不是一个 Go 包而是一个 Go+ 的包，会怎么？
后果显然是无奈辨认。咱们的解决方案比较简单，实现了一个 Go+ 版本的 packages.Load。
因为是 Go+ 代码，所以代码并不在 gox 中（gox 还是专一 Go AST 的生成），而是在 gop/cl/packages.go 文件中的 func(*PkgsLoader)Load 函数。
这个函数的根底逻辑如下：
先调用 packages.Load 来 import 依赖包。如果出错则 error 信息蕴含哪些包加载失败；
将加载失败的 Go+ 包编译成 Go 包。这个过程具体怎么做咱们上一讲曾经介绍过。最终咱们会在这个 Go+ 包所在目录下生成 gop_autogen.go 文件；
从新调用 packages.Load 来 import 该依赖包。因为写入了 go 文件，所以它曾经是一个非法的 Go 包，packages.Load 加载胜利。
这里这个过程的逻辑很相似于 CPU 内存治理的缺页解决。先尝试加载，加载失败相似于缺页中断，中断后加载缺页的内存（这里则是将 Go+ 包转换为 Go 包），而后继续执行（这里则是从新加载 Go+ 包）。从 gox 模块的角度来看，它其实不意识 Go+ 的包，但又能进行加载，这个过程十分天然并且乏味。
但这里可能还有最初一个问题，如果依赖的 Go+ 包还没有下载怎么办？
在 Go 当中，晚期是通过 go get 来进行包的下载，目前应用最多的办法是通过 go mod tidy 来下载所有依赖包所在的模块。
对于这个问题，咱们的思考是实现相似 gop mod tidy 的性能来实现 Go+ 包的主动下载，这个性能还没有实现，大家能够进行尝试。它的逻辑其实和下面的 import Go+ 包是很相似的。
- 如何治理 Go+ 模块
上面咱们谈谈 Go+ 的模块管理机制。它有两种可能的抉择：
基于 Go Module(go.mod) 治理
本人实现 Go+ Module(gop.mod) 治理
因为 Go+ 能在本人的目录中生成 Go 文件，来让本人模仿成 Go 包，因而能够借助 Go 的工具链以及 Go 模块管理机制来实现对 Go+ 的治理与应用。这是一个比拟偷懒但绝对容易实现的机制。
而本人实现 Go+ Module(gop.mod) 治理，与上述形式相比会有些不同，咱们来进行一下具体的比照。
目前咱们采纳的形式便是基于 Go 的模块治理，它最大的劣势就是容易实现、简略，不必额定做什么，躺平就行了。但劣势在于，编译一个哪怕最简略的 Go+ 程序也须要援用 Go+ 规范库，因为其中有一个非凡的库叫 buitin，也就是内建库。对这个库的依赖会导致要把对 Go+ 规范库的援用加到所有 Go+ 模块的 go.mod 文件中，这会让 Go+ 的使用者会感觉十分不不便，而且很容易呈现各种奇怪的问题。
这个问题咱们在思考如何彻底去解决。目前的思路便是实现 Go+ 本人的 Module 治理，通过 gop.mod 文件来主动生成 go.mod。而更新 go.mod 的机会比较简单，当每次 gop.mod 文件更新时，咱们便从新生成一次 go.mod。
所以对于 Go+ 模块来说，go.mod 文件就无需写在入库，因为它是主动生成的。主动生成中额定减少的次要就是对 Go+ 规范库的援用，它通过 replace 指令来实现。用 replace 咱们能够做到援用的永远是本地的 Go+ 规范库，这相当于对 gop tools 与 Go+ 的规范库进行了一次主动对齐。
后面咱们说容易出各种奇怪的问题，次要就是在基于 Go Module 机制下，gop tools 咱们可能曾经更新到最新了，然而 go.mod 文件外面的 Go+ 规范库可能是很老的版本，这种不统一有时就会产生奇怪的问题。
而通过 Go+ Module 文件主动生成 Go Module 文件，这样既可实现对 Go 工具链无缝的协同，复用了 Go 工具链，又能够解决 gop tools 和 Go+ 规范库版本不匹配的问题。
三. 练习题
首先咱们更新一下公开课第 1 期练习题的状态。外面咱们最期待被实现的 Range 表达式曾经有人实现，最新的 Go+ 版本曾经带了这个性能。咱们在常识星球 Go+ 公开课中也介绍了这个新性能。欢送大家到常识星球 Go+ 公开课具体理解。
- 根底练习
1) 解决 gop cache 更新问题
issues 地址：
http://github.com/goplus/gop/…
$ModRoot/.gop/gop.cache 以后只能感知到本 Module 内的更新，对于模块外的依赖如果产生扭转，并不能正确进行检测。长期计划为手工删除 gop.cache 文件，欢送大家来解决这个问题。
2) import “pkgPath” 问题
issues 地址：
http://github.com/goplus/gop/…
谨严来说，真正实现 import “pkgPath” 须要先加载依赖包来失去这个包的别名 pkgName。目前并不加载依赖包，而是简略 pkgName = path.Base(pkgPath)。这在大部分状况下是对的，但并不谨严。
这个问题比较简单，而且遇到问题开发人员很容易绕过（通过手工指定 pkgName），所以优先级不高，适宜作为根底练习。
3) import local package
issues 地址：
http://github.com/goplus/gop/…
这个状况在理论环境中很少应用，只是从兼容性角度思考心愿减少该实现。它在上一讲中也作为练习讲过，这里不开展。
- 进阶练习
1) 实现 gop mod tidy
issues 地址：
http://github.com/goplus/gop/…
2) 实现 Go+ Module（gop.mod）
issues 地址：
http://github.com/goplus/gop/…
3) 批改 packages.Load 自身，让屡次 Load 之间能够共享依赖包
issues 地址：
http://github.com/goplus/gop/…
咱们也会帮助大家解决训练过程中遇到的问题。联系方式如下：
- Go+ 用户群（微信群）：能够间接在群里提出问题并 @我，我会间接在社群进行解答；
- Go+ 公开课（常识星球）：本次演讲的 PPT 及文字内容会同步在常识星球中，欢送在下面发问交换。