GO1.11 Module全攻略

为了不再每次新建工程都要拷贝一大堆Github的库文件。特意学习了下1.11的最新库文件管理模块，Module。

之前的管理方式有Vendor,GoVendor,GoDep,Dep,Glide等等。因为官方说1.12还会迟滞Modue这个功能，所以之前的就不必学了，况且之前的这些Github项目的上传者看到Go出了官方工具后，纷纷表态不再更新自己的库管理项目，最多维护一段时间。

所以来Go Module。一劳永逸。

1.先说GOPATH环境变量。理解了GOPATH变量，就明白启用GOModule之前和之后的变化。

GOPATH用来解析import语句。列出了查找Go代码的位置。如果设置就是设置的值，如果没有设置则使用默认值，默认值使用go env GOPATH可查看值。GOPATH设置的目录下有固定结构：

src：目录包含源代码。src下面的路径确定导入路径或可执行文件名。

pkg：目录包含已安装的包对象。每个目标操作系统和体系结构对都有自己的子目录pkg（pkg / GOOS_GOARCH）。

bin目录保存已编译的命令。每个命令都以其源目录命名，但仅以最终元素命名，而不是整个路径。

也就是说，DIR / src / foo / quux中带有源的命令安装在DIR / bin / quux中，而不是DIR / bin / foo / quux中。剥离“foo /”前缀，以便您可以将DIR / bin添加到PATH以获取已安装的命令。如果设置了GOBIN环境变量，则命令将安装到它命名的目录而不是DIR / bin。GOBIN必须是绝对的道路。

在某些IDE中除了会引入环境变量的GOPATH所代表的值，还可以设置属于当前项目自己的多个GOPATH值。

Go搜索GOPATH中列出的每个目录以查找源代码，但新包始终下载到列表中的第一个目录中。

需要注意的是：在1.11版本中，GOPATH不再用于解析。但仍然用于存储下载的源代码（在GOPATH / pkg / mod中）和编译的命令（在GOPATH / bin中）。

2.先设置GO111MODULE，有三个值，on, off , auto, on 是强制所有Go项目都启用Module，off相反，auto则根据当前项目是否在GOPATH / src下，是则不开启，否在开启。

3.在这里Go module的使用分为几种情况，

a.1.10使用非Go Module的管理模式，现在要改造成符合GoModule管理的形式。

b.直接新建工程，使用GoModule模式。

其实这两种情况大同小异，唯一不同的是目录结构，旧的项目中肯定包含src目录，新的目录不必再必须新建src这个目录。

下面就以第一种方式a的情况为例。看看怎么使用go module. 

A.第一种方式直接在之前旧目录的src下main.go所在的目录中 打开cmd，输入 go init module名，这里以X5为例， 就可以了会发现新生成了一个go.mod文件，里面第一行内容为 module x5.

PS：值得一提的是在已经使用现有依赖关系管理工具（如godep，glide或dep）的项目中，“go mod init”还将添加与现有配置匹配的require语句。

B.一旦go.mod文件存在，就不需要额外的步骤：像'go build'，'go test'，甚至'go list'这样的命令会根据需要自动添加新的依赖项来满足导入。

这些命令一旦运行，（在包含让main函数运行的目录中运行），则开始在当前目录查找mod文件，或者当前目录的父目录，或父目录的父目录，来查找各个模块的根目录，最后根据代码中的引用确定在mod文件中加入哪些依赖项。

需要注意的是依赖模块中的任何replace和exclude语句都将被忽略。因此，replace和exclude语句允许主模块完全控制其自己的构建，而不受依赖项的完全控制。所以，主模块依赖的包里的库版本其实是不起作用的，最终起作用的是放在主模块的mod文件中的版本。

mod文件 通过 require,replace,exclude三个命令来使用精确的软件包。

提供构建包的模块集称为“构建列表”。构建列表最初仅包含主模块。然后，go命令以递归方式向列表添加列表中已有模块所需的确切模块版本，直到没有任何内容可添加到列表中。如果将特定模块的多个版本添加到列表中，则最后仅保留最新版本（根据语义版本排序）以用于构建。

'go list'命令提供有关主模块和构建列表的信息。例如：