Go Modules
Go Modules
$ mkdir -p /tmp/scratchpad/hello
$ cd /tmp/scratchpad/hello
然后可以用 go mod init example.com/m
生成
module example.com/m
require (
golang.org/x/text v0.3.0
gopkg.in/yaml.v2 v2.1.0
rsc.io/quote v1.5.2
)
replace (
golang.org/x/text => github.com/golang/text v0.3.0
)
然后照常编写
// hello.go
package main
import (
"fmt"
"rsc.io/quote"
)
func main() {
fmt.Println(quote.Hello())
}
在执行 go build
命令之后,即可以在
模块结构
模块是包含了
module my/thing
require (
one/thing v1.3.2
other/thing v2.5.0 // indirect
...
)
exclude (
bad/thing v0.7.3
)
replace (
src/thing 1.0.2 => dst/thing v1.1.0
)
需要注意的是,该文件中声明的依赖,并不会在模块的源代码中使用
目录结构
一般来说,我们在
// go.mod
module myprojectname
// or
module github.com/myname/myproject
然后用如下方式导入其他模块:
import myprojectname/stuff
import github.com/myname/myproject/stuff
外部依赖
模块依赖项会被下载并存储到 GOPATH/src/mod
目录中,直接后果就是废除了模块的组织名称。假设我们正在开发的项目依赖于

go list -m all
来查看全部的依赖,使用 go mod tidy
来移除未被使用的依赖,使用 go mod vendor
可以生成独立的
模块代理
$ go env -w GO111MODULE=on
$ go env -w GOPROXY=https://goproxy.cn,direct
Go Module 问题
Go 命令的副作用
Go list,Go test,Go build,所有命令都会去拉取依赖,有些库是用被墙的服务做了重定向,只是执行一下
按照 “By design” 的说法,
解法:配置
形同虚设的semver 规范
社区里不遵守
无法应对删库
即使看起来我们可以靠
Github release/tag 水土不服
在
goproxy 的实现并不统一
不知道是否是因为
而
go get 到的lib 版本在go build 时被修改
在
版本信息扩散
由于
go.sum 合并冲突
因为上面讲到的一系列问题,
Links
- https://mp.weixin.qq.com/s/Sxv5qb-v6OIhPptLWAHYUw
Go Module 来了,企业私有代理你准备好了吗? - https://colobu.com/2021/07/04/dive-into-go-module-3/?hmsr=toutiao.io 深入
Go Module 之未说的秘密