如何在 go.mod 中最好地声明 golang 依赖版本？

积累知识，胜过积蓄金银！毕竟在Golang开发的过程中，会遇到各种各样的问题，往往都是一些细节知识点还没有掌握好而导致的，因此基础知识点的积累是很重要的。下面本文《如何在 go.mod 中最好地声明 golang 依赖版本？》，就带大家讲解一下知识点，若是你对本文感兴趣，或者是想搞懂其中某个知识点，就请你继续往下看吧~

在 go mod 中声明依赖项版本的经典方法是通过

require (
    k8s.io/api v0.17.4
    k8s.io/apimachinery v0.17.4
    k8s.io/cli-runtime v0.17.0
    k8s.io/client-go v0.17.4
)

过去（go <= 1.12？）这已被解析为时间戳版本，但最近版本保持不变。

但是，我也见过这种固定版本的技术：

require (
    k8s.io/api v0.17.4
    k8s.io/apimachinery v0.17.4
    k8s.io/client-go v11.0.1-0.20190805182717-6502b5e7b1b5+incompatible
    k8s.io/code-generator v0.18.0
    k8s.io/kube-openapi v0.0.0-20191107075043-30be4d16710a
)

replace (
    k8s.io/api => k8s.io/api v0.16.4
    k8s.io/client-go => k8s.io/client-go v0.16.4
    k8s.io/code-generator => k8s.io/code-generator v0.16.4
    k8s.io/kube-openapi => k8s.io/kube-openapi v0.0.0-20190816220812-743ec37842bf
)

问题是为什么人们会选择一种方法而不是另一种？后者是否需要解决来自传递依赖项的冲突版本？如果是这样，为什么不应该从一开始就只将版本添加到 replace() 子句中以保持精确（不仅在冲突的情况下）？

解决方案

当您想在当前模块中使用特定版本的依赖项时，替换会很有帮助：

• 您可能想使用该版本，因为它是一个包含您需要的修改的分支。

  require example.com/original v1.0.0
  replace example.com/original => github.com/... v1.0.1

  （注意：您可以将 v1.0.1 替换为 master （或其他分支），并且下次 build/test/mod tidy 时它将被替换为伪版本。）

• 由于某种原因，您可能无法更改此特定依赖项的次要版本。也许需要额外的测试来验证行为，或者您可能已经尝试过较新的版本但它们不起作用。

• 您可能要对多个项目进行更改，或者单个存储库中有多个模块，并且您希望在开发时能够同时跨所有模块进行更改。

为了使替换有意义，您需要取决于您要替换的模块。您可以使用 require 在 go.mod 中添加依赖项，因此您不能仅使用 replace。

replace 需要额外的维护工作，一般情况下不需要更换所有内容。 replace 应在必要时选择性使用，如上述情况。

最后，添加替换并不会使版本选择更加“精确”。添加替换会使依赖项更新变得更加困难。人们很可能需要进去说：“是的，我们确实想要升级这个依赖项”，而不是让最小版本选择来决定何时升级依赖项，这可能会在没有升级的情况下意外发生。人类的注意。如上所述，这对于某些项目可能是不利的。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《如何在 go.mod 中最好地声明 golang 依赖版本？》文章吧，也可关注golang学习网公众号了解相关技术文章。