Golang1.5到Golang1.12包管理：golang vendor 到 go mod

1. 前言

Golang 是一门到如今有十年的静态高级语言了，2009年的时候算是正式推出了，然后到最近的一两年，2017-2018年的时候，突然直线上升，爆火了，得益于容器化运维/直播/短视频/区块链...

Golang 语法简单，简单即是复杂，软件构建的核心在于将复杂的东西简单化，处理好复杂度。

作为一个 gopher，我们要知道他的包管理，这样才能合理化代码结构，做好工程管理。（gopher：地鼠）

2. GOPATH/ Golang 1.5之前

Golang 的包管理一直让人口病，一开始它用 GOPATH 来进行依赖库管理，特别简单粗暴。

如果环境变量：

export GOROOT=/home/love/go
export GOPATH=/home/love/code
export GOBIN=$GOROOT/bin

上面 GOROOT 是指 Golang编译器以及其工具链，基础源码库所在的目录， GOPATH 是用户自定义的代码所在位置。

以下 GOPATH 的结构如下：

├── src
    └── github.com
        └── hunterhug
            └── rabbit
                └── a
                    └── a.go
                └── main.go
├── bin
├── pkg

我们写的开发包有简单易懂的路径之分，比如我的包叫 github/hunterhug/rabbit，那么结构如上面一样。

我们进入到 rabbit 目录，main.go 代码：

package main
import "github/hunterhug/rabbit/a"

func main(){
  ...
}

然后 go build 的话，找包时，就会从 GOPATH src 下面开始找，比如 rabbit 包下的 main.go 依赖了 github/hunterhug/rabbit/a，那么它首先从 src 下面按路径往下拼接查找，然后就找到了，最后生成和包名 github/hunterhug/rabbit 一样的一个叫 rabit 的二进制。

如果我们 go install的话，这个二进制就会保存在 GOBIN 下（如果不存在 GOBIN，会保存在 GOPATH bin 下）。如果我们要编译时，缺少包，那么 go get -v 将会下载依赖包源码到 GOPATH src 下，然后在 GOPATH pkg 目录下生成该包的静态库（下次用就不用再从源码编译了，算缓存）。

但是我们包找不到时：

love@love:~/code/src/github.com/hunterhug/fafacms$ go build
core/server/server.go:4:2: cannot find package "github.com/gin-contrib/cors" in any of:
        /home/love/go/src/github.com/gin-contrib/cors (from $GOROOT)
        /home/love/code/src/github.com/gin-contrib/cors (from $GOPATH)

我们发现，原来，其实是先去 GOROOT 下找包，找不到包，再去 GOPATH 找，流下了感动的泪水！比如我们的 GOPATH 下建了一个 fmt 包：

package fmt

func PPrintln() {
    print("i am diy fmt")
}

但是我们想引用这个库，main.go 使用：

package main
import fmt
func main(){
  fmt.PPrintln()
}

发现引用不了，2333！所以，GOPATH 下的包最好不要和 GOROOT 下的标准库重名！

你再看下 GOROOT 的结构:

├── src
    └── time
    └── fmt
├── bin
├── pkg

这不和我们的 GOPATH 很像吗，对，现在的 Golang编译器 是自编译的，就是用 Golang 来写 Golang编译器，它的编译器及中间产物，基础库等，保持和 GOPATH 一毛一样，无缝衔接。

但是不同依赖包是有版本的，版本变了怎么办？这就需要人工管理了。

3. Golang vendor/Golang1.5以后

自己管理库版本，想想都不太可能，毕竟 Java 有 maven, Python 有 pip, PHP 有 compose，NodeJs 有 npm。

于是从 Golang1.5 开始推出 vendor 文件夹机制（ vendor：供应商/小贩）。

从 Golang1.6 正式开启这个功能。

比如我们的包叫 awesomeProject，在 GOPATH 下结构：

├── src
    └── awesomeProject
        └── vendor
            └── fmt
                └── fmt.go
        └── main.go
├── pkg

其中 main.go：

package main

import "fmt"

func main() {
    fmt.PPrintln()
}

我们进入 awesomeProject 目录，并且 go build，偶也成功。

这下子不会像上面没 vendor 时直接引用 GOROOT 的标准包了，我们终于可以用和标准包重名的包了，那就是放在和 main.go 同目录的 vendor 下面！

这下子，我们 import 的包会先在同级 vendor 下找，找不到再按照以前的方式。

如果我们将 main 改成引用一个不存在的包 b:

package main

import (
    "b"
)

func main() {
    b.P()
}

然后 go build 提示：

main.go:4:2: cannot find package "b" in any of:
        /home/love/code/src/awesomeProject/vendor/b (vendor tree)
        /home/love/go/src/b (from $GOROOT)
        /home/love/code/src/b (from $GOPATH)

如果此时我们再任性一点，在 GOPATH src 下建立一个空的 vendor 文件夹，则会提示：

main.go:4:2: cannot find package "b" in any of:
        /home/love/code/src/awesomeProject/vendor/b (vendor tree)
        /home/love/code/src/vendor/b
        /home/love/go/src/b (from $GOROOT)
        /home/love/code/src/b (from $GOPATH)

好了，我们发现现在的加载方式是:

包同目录下的vendor
GOPATH src 下的vendor
GOROOT src
GOPATH src

如果在 GOROOT 和 GOPATH 下建 vendor 会怎么样？我们就不止疼了，233。。

好了，现在问题就是 vendor 是怎么冒泡的，如果我 main.go 引用了 vendor/b，而 b 包里面引用了一个 c 包。此时 vendor/b 会怎么找库？

├── src
    └── awesomeProject
        └── vendor
            └── b
                └── b.go
        └── main.go
├── pkg

现在 vendor/b/b.go 的内容：

package b

import "c"

func P() {
    print(" i am vendor b\n")
    c.P()
}

我们进入 awesomeProject 项目 go build，出现：

vendor/b/b.go:3:8: cannot find package "c" in any of:
    /home/love/code/src/awesomeProject/vendor/c (vendor tree)
    /home/love/code/src/vendor/c
    /home/love/go/src/c (from $GOROOT)
    /home/love/code/src/c (from $GOPATH)

现在加载流程是：

包同目录的包（即b包同目录看看有没有c包）
GOPATH src 下的vendor
GOROOT src
GOPATH src

此时我们在 vendor/b 下建一个空 vendor：

├── src
    └── awesomeProject
        └── vendor
            └── b
                └── vendor
                └── b.go
        └── main.go
├── pkg

进入 awesomeProject 项目再 go build 会出现：

vendor/b/b.go:3:8: cannot find package "c" in any of:
    /home/love/code/src/awesomeProject/vendor/b/vendor/c (vendor tree)
    /home/love/code/src/awesomeProject/vendor/c
    /home/love/code/src/vendor/c
    /home/love/go/src/c (from $GOROOT)
    /home/love/code/src/c (from $GOPATH)

如果我们再满足上面的 c 包，同理在 c 包建一个空 vendor ：

├── src
    └── awesomeProject
        └── vendor
            └── b
                └── vendor
                    └── c
                        └── vendor
                        └── c.go
                └── b.go
        └── main.go
├── pkg

但 c 包 c.go 引用了不存在的 d 包：

package c

import "d"

func P() {
    d.P()
}

进入 awesomeProject 项目再 go build 会出现：

vendor/b/vendor/c/c.go:3:8: cannot find package "d" in any of:
    /home/love/code/src/awesomeProject/vendor/b/vendor/c/vendor/d (vendor tree)
    /home/love/code/src/awesomeProject/vendor/b/vendor/d
    /home/love/code/src/awesomeProject/vendor/d
    /home/love/code/src/vendor/d
    /home/love/go/src/d (from $GOROOT)
    /home/love/code/src/d (from $GOPATH)

发现，查找包 vendor 是往上冒泡的，一个包引用另一个包，先看看同目录 vendor 下有没有这个包，没有的话一直追溯到上一层 vendor 看有没有，没有的话再上一层
vendor，直到 GOPATH src/vendor。

所以现在的加载流程是：

包同目录下的vendor
包目录向上的最近的一个vendor
...
GOPATH src 下的vendor
GOROOT src
GOPATH src

总结： vendor 向上冒泡！！！！

这样的话，我们可以把包的依赖都放在 vendor 下，然后提交到仓库，这样可以省却拉取包的时间，并且相对自由，你想怎么改都可以，你可以放一个已经被人删掉的 github 包在 vendor 下。这样，依然手动，没法管理依赖版本。

所以很多第三方，比如 glide , godep, govendor 工具出现了，使用这些工具，依赖包必须有完整的 git 版本，然后会将所有依赖的版本写在一个配置文件中。

比如 godep ：

go get -v github.com/tools/godep

在包下执行

godep save

会生成 Godeps/Godep.json记录依赖版本，并且将包收集于当前vendor下。

3. go mod/Go1.11以后

Golang 1.11 开始，实验性出现了可以不用定义 GOPATH 的功能，且官方有 go mod 支持。Golang 1.12 更是将此特征正式化。

现在用 Golang1.12 进行：

go mod init
go: modules disabled inside GOPATH/src by GO111MODULE=auto; see 'go help modules'

其中 GO111MODULE=auto 是一个开关，开启或关闭模块支持，它有三个可选值： off/on/auto，默认值是 auto。

GO111MODULE=off，无模块支持，和之前一样。
GO111MODULE=on，模块支持，忽略 GOPATH 和 vendor 文件夹，只根据 go.mod下载依赖。
GO111MODULE=auto，该项目在 GOPATH src 外面且根目录有 go.mod 文件时，开启模块支持。

在使用模块的时候， GOPATH 是无意义的，不过它还是会把下载的依赖储存在 GOPATH/src/mod 中，也会把 go install 的结果放在 GOPATH/bin（如果 GOBIN 不存在的话）

我们将项目移出 GOPATH，然后:

go mod init

出现：

go: cannot determine module path for source directory /home/love/awesomeProject (outside GOPATH, no import comments)

现在 main.go 改为：

package main // import "github.com/hunterhug/hello"

import (
    "b"
)

func main() {
    b.P()
}

将会生成 go.mod:

module github.com/hunterhug/hello

go 1.12

此时我们：

go build
build github.com/hunterhug/hello: cannot load b: cannot find module providing package b

这下没法查找 vendor 了，我们加上参数再来：

go build -mod=vendor
build github.com/hunterhug/hello: cannot load c: open /home/love/awesomeProject/vendor/c: no such file or directory

流下了感动的泪水， vendor 冒泡呢？原来启用了 go.mod，vendor 下的包 b 无法找到b/vendor 下的包 c，只能找到一级，2333333，这是好还是坏？

一般情况下， vendor 下面有 vendor 是不科学的， godep 等工具会将依赖理顺，确保只有一个 vendor。

那么 go.mod 导致 vendor 无法冒泡产生的影响，一点都不大，流下感动的泪水。

现在我们来正确使用 go mod，一般情况下：

省略N步

到了这里，我们很遗憾的说再见了，现在 go mod 刚出来，可能还会再更新，您可以谷歌或者其他方式搜索这方面的文章，或者：

go help modules

这一部分可能隔一段时间再细写。

目前生产环境用 go mod 还不太现实，我还是先推荐定义 GOPATH 和 vendor 用法。

4. 使用 Docker 来多阶段编译 Golang

装环境太难，我的天啊，我每次都要装环境，我们可以用下面的方法 So easy 随时切换 Golang 版本。

如果你的 Golang 项目依赖存于 vendor 下，那么我们可以使用多阶段构建并打包成容器镜像，Dockefile 如下：

FROM golang:1.12-alpine AS go-build

WORKDIR /go/src/github.com/hunterhug/fafacms

COPY core /go/src/github.com/hunterhug/fafacms/core
COPY vendor /go/src/github.com/hunterhug/fafacms/vendor
COPY main.go /go/src/github.com/hunterhug/fafacms/main.go

RUN go build -ldflags "-s -w" -o fafacms main.go

FROM alpine:3.9 AS prod

WORKDIR /root/

COPY --from=go-build /go/src/github.com/hunterhug/fafacms/fafacms /bin/fafacms
RUN chmod 777 /bin/fafacms
CMD /bin/fafacms $RUN_OPTS

其中 github.com/hunterhug/fafacms 是你的项目。使用 golang:1.12-alpine 来编译二进制，然后将二进制打入基础镜像：alpine:3.9，这个镜像特别小。

编译：

sudo docker build -t hunterhug/fafacms:latest .

我们多了一个镜像 hunterhug/fafacms:latest , 而且特别小，才几M 。

运行：

sudo docker run -d  --net=host  --env RUN_OPTS="-config=/root/fafacms/config.json" hunterhug/fafacms

可是，如果我们用了 cgo，那么请将 Dockerfile 改为：

FROM golang:1.12 AS go-build

WORKDIR /go/src/github.com/hunterhug/fafacms

COPY core /go/src/github.com/hunterhug/fafacms/core
COPY vendor /go/src/github.com/hunterhug/fafacms/vendor
COPY main.go /go/src/github.com/hunterhug/fafacms/main.go

RUN go build -ldflags "-s -w" -o fafacms main.go

FROM bitnami/minideb-extras-base:stretch-r165 AS prod

WORKDIR /root/

COPY --from=go-build /go/src/github.com/hunterhug/fafacms/fafacms /bin/fafacms
RUN chmod 777 /bin/fafacms
CMD /bin/fafacms $RUN_OPTS

5. 总结

管理依赖，到如何将代码编译成二进制，是一个过程，还有许多细节。上面是我的经验，感谢阅读。

Golang1.5到Golang1.12包管理：golang vendor 到 go mod

1. 前言

2. GOPATH/ Golang 1.5之前

3. Golang vendor/Golang1.5以后

3. go mod/Go1.11以后

4. 使用 Docker 来多阶段编译 Golang

5. 总结

9527

引用和评论

数据结构和算法(Golang实现)(30)查找算法-2-3-4树和普通红黑树

Go 语言-计算密集型服务性能优化

IO 密集型服务耗时优化

Go 语言 JSON 与 Cache 库调研与选型

Go 程序如何实现优雅退出？来看看 K8s 是怎么做的——上篇

Go 语言-内存泄漏排查两例

Golang GC 从原理到优化

Golang1.5到Golang1.12包管理：golang vendor 到 go mod

1. 前言

2. GOPATH/ Golang 1.5之前

3. Golang vendor/Golang1.5以后

3. go mod/Go1.11以后

4. 使用 Docker 来多阶段编译 Golang

5. 总结

9527

引用和评论

数据结构和算法(Golang实现)(30)查找算法-2-3-4树和普通红黑树

Go 语言-计算密集型服务 性能优化

IO 密集型服务 耗时优化

Go 语言 JSON 与 Cache 库 调研与选型

Go 程序如何实现优雅退出？来看看 K8s 是怎么做的——上篇

Go 语言-内存泄漏排查两例

Golang GC 从原理到优化

Go 语言-计算密集型服务性能优化

IO 密集型服务耗时优化

Go 语言 JSON 与 Cache 库调研与选型