gomod的版本选择策略

• 1.11版本引入了Go Modules，默认GO111MODULE=off，需要手动修改至on才启动module模式。
• 1.13版本中默认GO111MODULE=auto，会自动检测是否包含go.mod，如果包含则启用module模式。
• 从1.14版本GoMod可供生产使用，并且鼓励所有用户从其他依赖关系管理系统迁移到Go Mod。
• 1.16版本默认GO111MODULE=on，即一直启动module模式。

通过require module version可以在go.mod文件中直接声明依赖项的版本，如require M v1.2.3。

如果在go.mod文件中未直接require声明引入依赖的版本，在运行go build/go test等命令时会自动查找合适的module，并使用最新的版本作为require直接添加到go.mod文件中。

例如：import对应依赖M最新标记的release版本是1.2.3，go.mod文件中将会出现require M v1.2.3，这表示M是允许>=v1.2.3版本的依赖项（

当项目中引入多个依赖，且部分存在依赖的同时有多个版本被引入时，Go是如何处理的呢？

更多内容分享，欢迎关注公众号：Go开发笔记

最小版本选择算法用于选择build中使用的所有modules的版本。对于build中的每个module，通过最小版本选择算法选择的版本始终是主module或其依赖项之一通过require指令显式列出的版本中语义最高的版本，简单来说就是：使用require中的最高版本。

例如：如果你的module，依赖的module A需要require D v1.0.0，依赖的module B需要require D v1.1.1，最小版本选择算法将会选择D的v1.1.1版本用于build。即使后期D有v1.2.0版本可用，未显式require至go.mod中，仍将使用v1.1.1版本用于build。

D v1.0.0 -> module A
                      --> mymod(D v1.1.1)
D v1.1.1 -> module B

如何查看build时选择的版本呢？

可以通过运行go list -m命令进行检查。

go list -m all可以查看所有依赖module的build版本。
go list -m moduleName可以查看指定依赖module的build版本。