以本模块为例(使用特定的提交，以便其他人看到)
git clone git://github.com/walles/moar
Set-Location moar
git checkout d24acdbf
我想用一种方式告诉GOgo "更新一切".假设该模块
将与最新版本的一切兼容.下面是我发现的五种方法
执行此操作时，假设每个都在干净的克隆上运行.这导致了19分中的go.mod分
线路:
go get -u
这会产生go.mod行(共14行):
go get -u
go mod tidy
这将导致13行中的go.mod行:
go mod tidy
如果我只是手动删除require中的所有内容，然后运行go mod tidy，那么
tl；博士
这就是您想要的:
go get -u
go mod tidy
您看到的不一致是由于软件固有的有机本质造成的.
使用您的示例，git://github.com/walles/moar中的Commit d24acdbf很可能是由维护人员签入的，而没有运行go mod tidy(解释了更长的19行).如果维护人员有，那么您将在末尾看到13行版本.
go get -u本身在拉入依赖项方面更具侵略性.此外，仅仅是将依赖项更新到其最新(兼容)版本这一事实本身可能会引入新的直接/间接依赖项(&；).如果您明天try 这样做，这些依赖项可能会进一步增加(一些子依赖项的最新版本增加了新功能，因此需要新的依赖项).因此，repo维护者修复特定(非最新)版本可能有合理的原因.
go mod tidy清除了这种激进的依赖性分析.
附注:认为依赖项在go mod tidy之后会缩小是一种常见的误解:跟踪go.sum，在某些情况下，此文件会在tidy之后增长(不过，在本例中不是这样)