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

【问题标题】：How to declare golang dependency versions best in go.mod?如何在 go.mod 中最好地声明 golang 依赖版本？
【发布时间】：2020-06-15 20:48:36
【问题描述】：

在 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

不过，我也 seen 将此技术用于 pin 版本：

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() 子句中（不仅仅是在冲突的情况下）？

【问题讨论】：

"在过去 (go
例如，我们一般使用replace，直到上游得到我们的补丁。通过替换，我们使用我们的固定版本而不进行任何代码更改，当上游更新时，我们提升版本并删除replace。这是一种根据需要覆盖版本的解决方案。希望这个解释能阐明其目的。
我理解这用于替换存储库或自定义分叉。并且可能覆盖 gomod 决定放入 require() 的版本（它也更新了该部分，因此它是一个“共享”文本部分（有点不幸）。但是总是使用 是一个好习惯 需要确保使用用户选择的版本？

标签： go go-modules

【解决方案1】：

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

您可能想要使用该版本，因为它是一个带有您需要修改的分支。
```
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 应在必要时选择性地使用，例如上述情况。

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

【讨论】：