Go Modules与GOPROXY 配置

golangd 配置go mod 在博文底部

摘抄自https://studygolang.com/articles/24544 go语言中文网 在原基础博客整理增长知识点 让你完全名表go mod
随着Go 1.13发布，GOPROXY默认值proxy.golang.org在中国大陆不能被访问。

七牛云顺势推出goproxy.cn，以利于中国开发者更好使用Go Modules，它是非盈利性的项目，首先感谢七牛云。

Windows下使用教程:

（1）升级到Go1.13

（2）运行<go env -w GO111MODULE=on> //开启mod

（3）运行<go env -w GOPROXY=https://goproxy.cn,direct> //设置七牛云goproxy代理

能够经过运行go env查看（2）、（3）步骤是否设置成功

（4）在项目跟目录下执行go mod init <OPTIONAL_MODULE_PATH>

执行成功后生成go.mod文件

其余指令

go get -u //更新现有的依赖
go mod tidy //整理模块（拉取缺乏的模块，移除不用的模块）
go mod download//下载依赖包
go mod graph //打印现有依赖结构
go mod vendor //将依赖复制到vendor下
go mod verify //校验依赖
go.mod文件解析
module：模块名称，使用指令go mod init <OPTIONAL_MODULE_PATH>可设置
require：依赖包列表以及版本
exclude：禁用依赖包列表
replace：替换依赖包列表
go：go版本号

goland编辑器中配置go mod

在goland的setting里设置启用Go Modules
goland Preference->Go->Go Modules(vgo) -> Enable Go Modules(vgo)intergration

勾选 Enable Go Modules(vgo)intergration 以后 ，

proxy配置(参考上图)
https://goproxy.cn
点击apply （应用）ok 便可。

______________________________________________________________
______________________________________________________________

---

gomod 的相关知识 摘抄自go 夜读 （author：盛傲飞）

go.mod

module sss

go 1.13

require (
	github.com/astaxie/beego v1.12.0
	github.com/go-sql-driver/mysql v1.4.1
	github.com/julienschmidt/httprouter v1.3.0
	github.com/micro/examples v0.2.0
	github.com/micro/go-micro v1.18.0
)

go.mod 是启用了 Go moduels 的项目所必须的最重要的文件，它描述了当前项目（也就是当前模块）的元信息，每一行都以一个动词开头，目前有如下 5 个动词:

• module：用于定义当前项目的模块路径。
• go：用于设置预期的 Go 版本。
• require：用于设置一个特定的模块版本。
• exclude：用于从使用中排除一个特定的模块版本。
• replace：用于将一个模块版本替换为另一个模块版本。

这里的填写格式基本为包引用路径+版本号，另外比较特殊的是 go $version，目前从 Go1.13 的代码里来看，还只是个标识做用，暂时未知将来是否有更大的做用。
go.sum
go.sum 是相似于好比 dep 的 Gopkg.lock 的一类文件，它详细罗列了当前项目直接或间接依赖的全部模块版本，并写明了那些模块版本的 SHA-256 哈希值以备 Go 在从此的操做中保证项目所依赖的那些模块版本不会被篡改。

example.com/apple v0.1.2 h1:WX...
example.com/apple v0.1.2/go.mod h1:xHW...
example.com/banana v1.2.3/go.mod h1:HS... 
...

example.com/apple v0.1.2 h1:WXk...
example.com/apple v0.1.2/go.mod h1:xH...

前者为 Go modules 打包整个模块包文件 zip 后再进行 hash 值，然后者为针对 go.mod 的 hash 值。他们二者，要不就是同时存在，要不就是只存在 go.mod hash。

那什么状况下会不存在 zip hash 呢，就是当 Go 认为确定用不到某个模块版本的时候就会省略它的 zip hash，就会出现不存在 zip hash，只存在 go.mod hash 的状况。

GO111MODULE
这个环境变量主要是 Go modules 的开关，主要有如下参数：

• auto：只在项目包含了 go.mod 文件时启用 Go modules，在 Go 1.13 中仍然是默认值，详见 ：golang.org/issue/31857。
• on：无脑启用 Go modules，推荐设置，将来版本中的默认值，让 GOPATH 今后成为历史。
• off：禁用 Go modules。

GOPROXY
这个环境变量主要是用于设置 Go 模块代理，主要以下：

• 它的值是一个以英文逗号 “,” 分割的 Go module proxy 列表（稍后讲解）
• 做用：用于使 Go 在后续拉取模块版本时可以脱离传统的 VCS 方式从镜像站点快速拉取。它拥有一个默认值，但很惋惜 proxy.golang.org 在中国没法访问，故而建议使用 goproxy.cn 做为替代。
• 设置为 “off” ：禁止 Go 在后续操做中使用任 何 Go module proxy。

刚刚在上面，咱们能够发现值列表中有 “direct” ，它又有什么做用呢？
其实值列表中的 “direct” 为特殊指示符，用于指示 Go 回源到模块版本的源地址去抓取 (好比 GitHub 等)，当值列表中上一个 Go module proxy 返回 404 或 410 错误时，Go 自动尝试列表中的下一个，碰见 “direct” 时回源，碰见 EOF 时终止并抛出相似 “invalid version: unknown revision…” 的错误。

GOSUMDB
它的值是一个 Go checksum database，用于使 Go 在拉取模块版本时(不管是从源站拉取仍是经过 Go module proxy 拉取)保证拉取到的模块版本数据未经篡改，也能够是“off”即禁止 Go 在后续操做中校验模块版本

• 格式: SUMDB_NAME+PUBLIC_KEY或SUMDB_NAME+PUBLIC_KEY SUMDB_URL。
• 拥有默认值： sum.golang.org (之因此没有按照上面的格式是由于 Go 对默认值作了特殊处理)。
• 可被 Go module proxy 代理 (详见：Proxying a Checksum Database)。
• GOSUMDB 的默认值在中国没法访问，故而更加建议将 GOPROXY 设置为 goproxy.cn，由于 goproxy.cn 支持代理 sum.golang.org。

Go Checksum Database
Go checksum database 主要用于保护 Go 不会从任何源头拉到被篡改过的非法 Go 模块版本，其做用（左）和工做机制（右）以下图：

若是有兴趣的小伙伴能够看看 Proposal: Secure the Public Go Module Ecosystem，有详细介绍其算法机制，若是想简单一点，查看 go helpmodule-auth 也是一个不错的选择。

GONOPROXY/GONOSUMDB/GOPRIVATE
这三个环境变量都是用在当前项目依赖了私有模块，也就是依赖了由 GOPROXY 指定的 Go module proxy 或由 GOSUMDB 指定 Go checksum database 没法访问到的模块时的场景，他们具备以下特性：

• 它们三个的值都是一个以英文逗号 “,” 分割的模块路径前缀，匹配规则同 path.Match。

• 其中 GOPRIVATE 较为特殊，它的值将做为 GONOPROXY 和 GONOSUMDB 的默认值，因此建议的最佳姿式是只是用 GOPRIVATE。

在使用上来说，好比 GOPRIVATE=*.corp.example.com 表示全部模块路径以 corp.example.com 的下一级域名 (如 team1.corp.example.com) 为前缀的模块版本都将不通过 Go module proxy 和 Go checksum database，须要注意的是不包括 corp.example.com 自己。
Global Caching
这个主要是针对 Go modules 的全局缓存数听说明，以下：

• 同一个模块版本的数据只缓存一份，全部其余模块共享使用。
• 目前全部模块版本数据均缓存在 $GOPATH/pkg/mod和 $GOPATH/pkg/sum 下，将来或将移至 $GOCACHE/mod和 $GOCACHE/sum 下( 可能会在当 $GOPATH 被淘汰后)。
• 可使用 go clean-modcache 清理全部已缓存的模块版本数据。

另外在 Go1.11 以后 GOCACHE 已经不容许设置为 off 了，我想着这也是为了模块数据缓存移动位置作准备，所以你们应该尽快作好适配。

++++++++++++++++++++++++=+++++++++++++++++=++++++++++++++++++++++++=+++++++++++++++++=++++++++++++++++++++++++=+++++++++++++++++=++++++++++++++++++++++++=+++++++++++++++++=++++++++++++++++++++++++=+++++++++++++++++=++++++++++++++++++++++++=+++++++++++++++++=++++++++++++++++++++++++=+++++++++++++++++=++++++++++++++++++++++++=+++++++++++++++++=++++++++++++++++++++++++=+++++++++++++++++=++++++++++++++++++++++++=+++++++++++++++++=

快速迁移项目至 Go Modules

• 升级到 Go 1.13。

• 让 GOPATH 从你的脑海中彻底消失，早一步踏入将来。

  • 修改 GOBIN 路径（可选）。
  • 打开 Go modules 的开关。
  • 设置 GOPROXY。

• 按照你喜欢的目录结构从新组织你的全部项目。

• 在你项目的根目录下执行 go mod init<OPTIONAL_MODULE_PATH> 以生成 go.mod 文件。

• 想办法说服你身边全部的人都去走一下前四步。

迁移后 go get 行为的改变

这里咱们注意到有两点比较特别，分别是：

• 第一点：为何 “拉取 hash 为 342b231 的 commit，最终会被转换为 v0.3.2” 呢。这是由于虽然咱们设置了拉取 @342b2e commit，可是由于 Go modules 会与 tag 进行对比，若发现对应的 commit 与 tag 有关联，则进行转换。
• 第二点：为何不建议使用 go mod vendor，由于 Go modules 正在淡化 Vendor 的概念，颇有可能 Go2 就去掉了。

使用 Go Modules 时常碰见的坑

坑 1: 判断项目是否启用了 Go Modules

坑 2: 管理 Go 的环境变量

这里主要是提到 Go1.13 新增了 go env-w 用于写入环境变量，而写入的地方是 os.UserConfigDir 所返回的路径，须要注意的是 go env-w 不会覆写。

坑 3: 从 dep、glide 等迁移至 Go Modules

这里主要是指从旧有的依赖包管理工具（dep/glide 等）进行迁移时，由于 BUG 的缘由会致使不通过 GOPROXY 的代理，解决方法有以下两个：

• 手动建立一个 go.mod 文件，再执行 go mod tidy 进行补充。
• 上代理，至关于不使用 GOPROXY 了。

坑 4:拉取私有模块

这里主要想涉及两块知识点，以下：

• GOPROXY 是无权访问到任何人的私有模块的，因此你放心，安全性没问题。
• GOPROXY 除了设置模块代理的地址之外，还须要增长 “direct” 特殊标识才能够成功拉取私有库。

坑 5:更新现有的模块

坑 6:主版本号

Q：使用 Go modules 时能够同时依赖同一个模块的不一样的两个或者多个小版本（修订版本号不一样）吗？

A：不能够的，Go modules 只能够同时依赖一个模块的不一样的两个或者多个大版本（主版本号不一样）。好比能够同时依赖 example.com/foobar@v1.2.3 和 example.com/foobar/v2@v2.3.4，由于他们的模块路径（module path）不一样，Go modules 规定主版本号不是 v0 或者 v1 时，那么主版本号必须显式地出如今模块路径的尾部。可是，同时依赖两个或者多个小版本是不支持的。好比若是模块 A 同时直接依赖了模块 B 和模块 C，且模块 A 直接依赖的是模块 C 的 v1.0.0 版本，而后模块 B 直接依赖的是模块 C 的 v1.0.1 版本，那么最终 Go modules 会为模块 A 选用模块 C 的 v1.0.1 版本而不是模块 A 的 go.mod 文件中指明的 v1.0.0 版本。

这是由于 Go modules 认为只要主版本号不变，那么剩下的均可以直接升级采用最新的。可是若是采用了最新的结果致使项目 Break 掉了，那么 Go modules 就会 Fallback 到上一个老的版本，好比在前面的例子中就会 Fallback 到 v1.0.0 版本。