起因
项目依据不同的逻辑，拆分成了多个公用模块，例如：处理通用功能的模块（common），常量定义模块（constant）等。由于多个项目都需要用到这些公用模块，合作开发时，使用go modules，引用公用包的时候，像这样replace common => ../common 不能保证每个人的项目目录层级和自己一样。所以，像引用github上的包那样引入自己本地搭建的包，在团队合作时，就会方便很多，也能在一定程度上保证代码的私有性（外部网络访问不了）。
如何使用
我本地的go版本为1.14.1，关键点就是要配置一下环境变量GOPRIVATE。
export GOPRIVATE=gitlab.com/xxx我本地的windows配置如下：
它可以声明指定域名为私有仓库，go get在处理该域名下的所有依赖时，会直接跳过GOPROXY和CHECKSUM等逻辑。
另外域名gitlab.com/xxx非常灵活，它默认是前缀匹配的，所有的gitlab.com/xxx前缀的依赖模块都会被视为private-modules，它对于企业、私有Group等有着一劳永逸的益处。
提示：如果你通过ssh公钥访问私有仓库，记得配置git拉取私有仓库时使用ssh而非https。
可以通过命令git config …的方式来配置。也可以像我这样，直接修改~/.gitconfig添加如下配置：
[url "git@gitlab.com:"]
insteadOf = https://gitlab.com/即可强制go get针对gitlab.com使用ssh而非https。
其他版本的go的配置，可见文末参考的第一篇文章。
go mod 简介
go modules是go官方的包管理工具，于1.11版本引入。
Modules是相关Go包的集合，是源代码交换和版本控制的单元。go命令直接支持使用Modules，包括记录和解析对其他模块的依赖性。Modules替换旧的基于GOPATH的方法，来指定使用哪些源文件。
Modules和传统的GOPATH不同，不需要包含例如src，bin这样的子目录，一个源代码目录甚至是空目录都可以作为Modules，只要其中包含有go.mod文件。
注意：使用modules时，GO111MODULE这个环境变量一定不能设置为off。其有三个值：
-
GO111MODULE = on即使项目在 GOPATH 中，仍将强制使用 Go 模块。需要go.mod正常工作。 -
GO111MODULE = off强制 Go 表现出 GOPATH 方式，即使在 GOPATH 之外。 -
GO111MODULE = auto是默认模式。在这种模式下，Go 会表现
- 当您在 GOPATH 外部时， 设置为 GO111MODULE = on，
- 当您位于 GOPATH 内部时，即使存在 go.mod, 设置为 GO111MODULE = off。
基本使用方式
#cd xxx // 进入项目目录
# go mod init xxx // mod初始化，xxx为项目名称更新引用的包
- 可手动删除go.mod文件中相关的引用，然后执行
go mod tidy - 直接
go get -u强制更新所有的依赖文件 - 若要更新指定版本的仓库，例：
go get -u gitlab.com/xxx@v1.0.1注意：mod有版本机制，所以对于经常会变化的引用的包，不建议使用mod机制，go mod提示如下：
因为mod 的版本机制，之前的版本都会保留
总结
- 引入私有包，需全局配置GOPRIVATE环境变量
- 若引入的包经常变化，不建议使用modules引入该包。若需要使用，在引用的库有更新时，需手动go get -u 获取下最新的仓库（注意：mod不会删除之前的版本仓库）。
- 注意git仓库的ssh和https获取方式的差异配置
参考
- Go填坑之将Private仓库用作module依赖Go填坑之将Private仓库用作module依赖
- Managing Dependency and Module Versioning Using Go Modules
- Go 模块解惑：到处都是 GO111MODULE ，这到底什么？
