go modules用法

自从 go 1.11开始，go modules已经可以使用，各大开源项目都在迁移中，未来glide、godep等 工具 均将成为过去式，现在学习正是时候。

今天在生产环境实践了go moudles，完全不依赖GOPATH，使用起来很方便，下面记录一下。

前提

• 不要export GOPATH，使用go modules就不要定义GOPATH，忘掉它即可。
• 一定要export GO111MODULE=on

GOPATH方案（过时）

以前基于GOPATH的玩法，我们下载自己的项目需要执行：

go get github.com/owenliang/go-ss

项目会下载到目录：

$GOPATH/src/github.com/owenliang/go-ss

如果要需要依赖，那么就继续：

go get github.com/gorilla/websocket

依赖会下载到目录：

$GOPATH/src/github.com/gorilla/websocket

我们代码中引用这个依赖，需要这么写：

import "github.com/gorilla/websocket"

然后go会去$GOPATH下面找这个路径，当然也会依据vendor机制向上查找，就不展开说明了。

那么GOPATH方案的缺点就是：

• 依赖库没有版本概念，都是master最新代码，因此也诞生了类似glide、godep等主流包管理工具。
• 开发项目竟然要先创建一个目录当做GOPATH，然后把自己的项目go get到一个很深的目录层级里面去，这太奇怪了！

go module方案（推荐）

使用该方案的时候，我们不需要GOPATH。

先下载项目到go-ss目录：

git clone github.com/owenliang/go-ss

然后直接用IDE打开go-ss目录进行开发即可。

打开go-ss项目后，我们需要先进行go modules的初始化：

go mod init github.com/owenliang/go-ss

这一步很关键，go modules虽然不需要用GOPATH了，但包的完整路径是不能变的，包名依旧叫做github.com/owenliang/go-ss，这样其他项目引用我们的时候还是写import “github.com/owenliang/go-ss”。

执行后就会生成一个go.mod和go.sum文件，其中go.mod明确写了我们包的完整名字：

module github.com/owenliang/go-ss

现在引入依赖和原先没有任何区别：

go get github.com/gorilla/websocket

但是我们观察go.mod，里面其实记录了当前websocket包到底用的是哪个版本：

module gitlab-team.smzdm.com/devops/zdevops/jumpserver
 
require (
	github.com/gorilla/websocket v1.4.0
）

我们在使用go get的时候还可以直接带上版本号，这就是多版本管理：

go get github.com/gorilla/websocket@v1.4.0

安装的包都被golang放在了GOROOT下面，进行了多版本的管理，我们就不需要操心了。

go modules的用法基本就是这样了。

其他

GOPROXY加速

golang很多包都会被GFW墙掉，现在有了go module就可以解决了。

go module支持配置镜像源，从而更快更稳定的完成go get操作，大家只需要export GOPROXY配置一下即可，推荐的源地址： https://goproxy.io/ 。

vendor依赖打包

我喜欢把项目依赖的包一起提交到git中，这样换一台服务器可以直接编译，不需要再去下载包依赖了。

我们在go.mod所在目录，通过命令go mod vendor即可把项目的依赖拷贝到vendor目录下，把vendor提交到git仓库即可。

如果我们用了vendor，那么编译程序的时候仅仅用go build是不够的，默认go modules不会使用vendor目录进行包查找，我们需要这样：

go build -mod vendor

更多学习资料

参考： 《go mod的使用》

博主无私的分享着知识，你愿意送他一顿热腾腾的早餐吗？