今天 Go 1.13 终于发布了,虽然比预期延迟了半个月之久,但毕竟迟到总比不到好。
Go 1.13 的发布为 Go 带来了不少变化(详见: https://golang.org/doc/go1.13 ),有些变化可能是开发者无法直接感觉到的,但有些又是和开发者日常开发息息相关的。其中,Go modules 的扶正就是这次 Go 1.13 发布中开发者能直接感觉到的最大变化。
Go modules 最早发布于 Go 1.11,经过两个版本的更新后,它作为依赖管理解决方案来说现在已经变得光彩夺目。随着 Go modules 一起被发布的还有一个叫做 Module proxy protocol 的协议,通过它我们可以搭建 Go 模块代理,最后交由 GOPROXY
环境变量以指引 go
命令后续在抓取模块时的途径。对于咱们中国的开发者来说,一个优秀的 Go 模块代理可以帮助我们解决很多问题。比如 Go 语言中最知名的 golang.org/x/...
模块在中国大陆是无法访问到的,以前我们会用很多其他的办法来抓取他们,而若依靠一个可以访问到它们的模块代理,那么将事半功倍。更因为 Go 1.13 将 GOPROXY
默认成了中国大陆无法访问的 https://proxy.golang.org ,所以我们中国的开发者从今以后必须先修改 GOPROXY
才能正常使用 go
来开发应用了。为此,我们联合中国备受信赖的云服务提供商七牛云专门为咱们中国开发者而打造了一个 Go 模块代理:goproxy.cn。
goproxy.cn 是目前中国最可靠的 Go 模块代理,这个如果有人存在质疑可以一一测试比对列表中所有能在国内访问的代理。对于那个和 goproxy.cn 域名比较相近的 goproxy.io,我之前已经发表过一篇实测文章(详见: https://studygolang.com/topics/9994 )。
goproxy.cn 还是是一个非营利性项目,目标是为中国和世界上其他地方的 Gopher 们提供一个免费的、可靠的、持续在线的且经过 CDN 加速的模块代理。正因为 goproxy.cn 由中国 Go 语言第一个吃螃蟹的大公司七牛云运行,所以它的稳定性和运行速度都是毋庸置疑的,如果你的网络环境本身不差的情况下,它能快到让你不可思议,比 go get
传统的抓取方式快上了不止几倍。有人可能会问阿里云的那个 mirrors.aliyun.com/goproxy 也很快,而且阿里云也是大厂,为什么不用阿里云的模块代理。我只能说,当我在使用阿里云的代理做初始化 github.com/kubernetes/kubernetes 的测试时,出现了大量的 404 错误以至于初始化操作无法完成……而且它还不支持代理 GOSUMDB
的默认值也就是 sum.golang.org,因此你还得手动修改 GOSUMDB
才能够正常使用 go
。在速度旗鼓相当的情况下,为什么不考虑直接使用一个更稳定、高可用的呢?而且毕竟 goproxy.cn 这个域名也很好记不是嘛~你只用记住 goproxy
和 .cn
,就没了。
问:在 Go 1.13 中如何使用 goproxy.cn?
答:一条 go env -w GOPROXY=https://goproxy.cn,direct
即可。之所以在后面拼接一个 ,direct
,是因为通过这样做我们可以在一定程度上解决私有库的问题(当然,goproxy.cn 无法访问你的私有库)。这个 GOPROXY
设定的工作原理是:当 go
在抓取目标模块时,若遇见了 404 错误,那么就回退到 direct
也就是直接去目标模块的源头(比如 GitHub) 去抓取。而恰好,GitHub 等类似的代码托管网站的原则基本都是“你无权访问的你来说就是不存在的”,所以我才说通过这样设定可以在一定程度上解决私有库无法通过模块代理访问的问题。
问:在 Go 1.13 之前如何使用 goproxy.cn?
答:同样也是设置环境变量即可,但是得你手动配置,而且还不能使用上述的那个 ,direct
后缀,因为那是 Go 1.13 刚加的特性。详细配置方法可以参见 goproxy.cn 的 README 文件。
问:在 Go 1.13 中如何解决私有库问题?
答:在上述的回答中我有提到可以通过 Go 1.13 为 GOPROXY
新增的“代理列表”特性来为 goproxy.cn 做一个 fallback 选项,也就是 direct
(直接从目标模块源头抓取),它就是解决私有库问题的一种方案,但并不是一个完美的解决方案。
为此,Go 1.13 还推出了一个 GONOPROXY 环境变量
(详见: https://golang.org/cmd/go/#hdr-Environment_variables ),通过设置它我们可以实现控制让哪些 module path 忽略 GOPROXY
,无脑回源。比如 GONOPROXY=*.corp.example.com
就意味着 go
在抓取所有 corp.example.com
的三级子域名下的所有模块时都将忽略 GOPROXY
设置直接回源到目标模块的原地址。
问:在 Go 1.13 中如何防止从公共模块代理中抓取的模块被篡改?
答:Go 1.13 新推出了一个 GOSUMDB
(默认值是 sum.golang.org,国内无法访问),就是为了实现这个目的,它的值是一个可信任的模块校验和数据库地址,通过指定它,go
将在抓取完模块时(无论是否是经过模块代理抓取的)对所有模块进行哈希校验,只有和校验和数据库中现有的一致时才算抓取成功。同 GONOPROXY
一样,Go 1.13 也为 GOSUMDB
配对发布了一个 GONOSUMDB
,用法一致,作用是控制 go
应该忽略校验哪些 module path 下的模块。
问:分别设置 GONOPROXY
和 GONOSUMDB
很麻烦,有没有更好的办法?
答:有,Go 1.13 为了方便管理私有库规则,还推出了一个 GOPRIVATE
,可以简单地理解成通过设置它就同时设置了 GONOPROXY
和 GONOSUMDB
。
有疑问加站长微信联系(非本文作者)

棒棒哒!搞起来!
支持!
GOPROXY=direct,https://127.0.0.1:12333,https://goproxy.cn,https://goproxy.io,https://mirrors.aliyun.com/goproxy,https://athens.azurefd.net
解决了猥皮恩的问题,good
666
之前就在用了,感谢开发者感谢七牛,速度真的很快
.cn一些包无法获取,换回.io了
能具体说一下嘛?我好排查问题所在😊
官方人员0oO?? 目前遇到的是redis包的6.15.4版本无法获取
你好,是的,我是原作者,现在 goproxy.cn 虽然属于七牛云不属于我了,但是我还在负责维护。
是这样的,你说的这个不属于 goproxy.cn 的 bug,是它本身的模块存在问题,你请求 https://goproxy.cn/github.com/go-redis/redis/@v/v6.15.4.info 可以得到错误信息如下:
同样的,不只是 goproxy.cn,即使是 Go 官方的模块代理 proxy.golang.org 也是报了同样的错,你可以请求 https://proxy.golang.org/github.com/go-redis/redis/@v/v6.15.4.info 试试看。
9楼 @gojuukaze 并且,即使你去使用 goproxy.io 也会得到同样的错误信息,所以这的确不是属于模块代理的错误了:
昨天.io还可以的,今天是不行了
那这个你就可以去 go-redis/redis 那里提个 issue 问一下了,的确算是他们的问题。因为实质上 Go 模块代理之间并不存在多大的区别,除非搭建者本身编写错误。不同 Go 模块代理之间最大的区别在于哪个模块代理更快、更稳定,这就好比 Ubuntu 的 apt 镜像源一样,全球那么多能在国内访问的,可咱们用的不也就那几个嘛?所以选择 Go 模块代理,能节省时间、加快开发效率才是王道。
总之,以后如果你想使用 goproxy.cn 了,然后遇见什么问题了也可以随时去 goproxy/goproxy.cn 提 issue 的,我会尽快解答的。😄
看了你的博客,你是北林的呀,说不定我们之前还见过的。
矮油~校友啊?哈哈哈~
@gojuukaze @aofei 兄弟们巧了,我本科也是北林,是你们的大师兄了。哈哈哈哈
sum.golang.google.cn文档里有个这个说明,看帖子意思是sumdb也会走goproxy?
@aofei @polaris 我不是北林,我校acm协会和你们acm协会有联系,经常去你们那比赛
你好,模块代理是可以代理 sumdb 的,这个是 Go 的另外一个特性(详见:https://go.googlesource.com/proposal/+/master/design/25530-sumdb.md#proxying-a-checksum-database)。
另外 goproxy.cn 只支持代理 sum.golang.org,不支持别的。
参见acm大佬……
看过评论下大佬的教程