去更新所有模块

珍惜时间，勤奋学习！今天给大家带来《去更新所有模块》，正文内容主要涉及到golang等等，如果你正在学习Golang，或者是对Golang有疑问，欢迎大家关注我！后面我会持续更新相关内容的，希望都能帮到正在学习的大家！

问题内容

以这个模块为例（使用特定的提交，以便其他人看到我所看到的）：

git clone git://github.com/walles/moar
Set-Location moar
git checkout d24acdbf

我想要一种方法来告诉 Go“更新所有内容”。假设该模块将与最新版本的所有内容一起使用。以下是我发现的五种方法，假设每种方法都在干净的克隆上运行。这导致go.mod19 行：

go get -u

这导致go.mod14 行：

go get -u
go mod tidy

这导致go.mod13 行：

go mod tidy

如果我只是手动删除所有内容require并运行go mod tidy，我会得到 12 行。如果我只是手动删除所有内容require并运行go get -u，我会得到 11 行。我的问题是，为什么这些方法会产生不同的结果，做我想做的事情的“正确方法”是什么？

正确答案

tl;博士;

这就是你想要的：

go get -u
go mod tidy

您看到的不一致是由于软件固有的有机性质造成的。

使用您的示例，维护人员在没有运行的情况下签入d24acdbf了git://github.com/walles/moar最有可能的提交go mod tidy（解释了较长的 19 行）。如果维护者有，那么你会看到最后看到的 13 行版本。

go get -u就其本身而言，它在引入依赖项方面更具侵略性。此外，将依赖项更新到其最新（兼容）版本这一事实本身可能会引入新的直接/间接依赖项。如果您明天尝试这样做，这些依赖项可能会进一步增长（某些子依赖项的最新版本添加了新功能，因此它需要新的依赖项）。因此，repo 维护者修复特定（非最新）版本可能是有正当理由的。

go mod tidy清理了这种激进的依赖分析。

PS这是一个常见的误解，即依赖关系会在go mod tidy: tracking之后缩小go.sum，在某些情况下，这个文件会在 a 之后增长tidy（虽然，在这种情况下不是）

本篇关于《去更新所有模块》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于Golang的相关知识，请关注golang学习网公众号！