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 版本。

posted @ 2019-11-23 13:51  liulonglong  阅读(8048)  评论(0)  编辑  收藏  举报