为什么在 golang 模块目录内使用 go get -u 耗时较长，而在 golang 外部则完成得很快？

有志者，事竟成！如果你在学习Golang，那么本文《为什么在 golang 模块目录内使用 go get -u 耗时较长，而在 golang 外部则完成得很快？》，就很适合你！文章讲解的知识点主要包括，若是你对本文感兴趣，或者是想搞懂其中某个知识点，就请你继续往下看吧~

我的网络速度非常慢且不稳定。

本地运行的第一个观察

例如，当我在新的模块目录（其中包含 main.go）中运行 go get -u github.com/jinzhu/gorm 时。它打印出很多行，并且由于网络缓慢不稳定而在我的本地环境中永远无法成功完成。

但是如果我在模块目录之外运行相同的命令，它可以在合理的时间内完成，而无需任何标准输出。

远程运行第二次观察

我有一个位于美国的远程 vps 服务器。我在那里创建相同的模块目录，并在远程模块内运行相同的命令：go get -u github.com/jinzhu/gorm，go.mod 将具有以下内容：

require (
    cloud.google.com/go v0.39.0 // indirect
    github.com/denisenkom/go-mssqldb v0.0.0-20190515213511-eb9f6a1743f3 // indirect
    github.com/golang/mock v1.3.1 // indirect
    github.com/google/btree v1.0.0 // indirect
    github.com/google/pprof v0.0.0-20190515194954-54271f7e092f // indirect
    github.com/jinzhu/gorm v1.9.8 // indirect
    github.com/jinzhu/inflection v0.0.0-20190603042836-f5c5f50e6090 // indirect
    github.com/kr/pty v1.1.4 // indirect
    github.com/lib/pq v1.1.1 // indirect
    go.opencensus.io v0.22.0 // indirect
    golang.org/x/crypto v0.0.0-20190530122614-20be4c3c3ed5 // indirect
    golang.org/x/exp v0.0.0-20190510132918-efd6b22b2522 // indirect
    golang.org/x/image v0.0.0-20190523035834-f03afa92d3ff // indirect
    golang.org/x/lint v0.0.0-20190409202823-959b441ac422 // indirect
    golang.org/x/mobile v0.0.0-20190509164839-32b2708ab171 // indirect
    golang.org/x/mod v0.1.0 // indirect
    golang.org/x/net v0.0.0-20190603091049-60506f45cf65 // indirect
    golang.org/x/oauth2 v0.0.0-20190523182746-aaccbc9213b0 // indirect
    golang.org/x/sys v0.0.0-20190602015325-4c4f7f33c9ed // indirect
    golang.org/x/time v0.0.0-20190308202827-9d24e82272b4 // indirect
    golang.org/x/tools v0.0.0-20190603152906-08e0b306e832 // indirect
    google.golang.org/appengine v1.6.0 // indirect
    google.golang.org/genproto v0.0.0-20190530194941-fb225487d101 // indirect
    google.golang.org/grpc v1.21.0 // indirect
    honnef.co/go/tools v0.0.0-20190602125119-5a4a2f4a438d // indirect
)

然后我运行 go mod tidy，go.mod 变为：

require (
    cloud.google.com/go v0.39.0 // indirect
    github.com/denisenkom/go-mssqldb v0.0.0-20190515213511-eb9f6a1743f3 // indirect
    github.com/google/go-cmp v0.3.0 // indirect
    github.com/jinzhu/gorm v1.9.8
    github.com/jinzhu/inflection v0.0.0-20190603042836-f5c5f50e6090 // indirect
    github.com/lib/pq v1.1.1 // indirect
    golang.org/x/crypto v0.0.0-20190530122614-20be4c3c3ed5 // indirect
    google.golang.org/appengine v1.6.0 // indirect
)

但是，如果我从 go.mod 中完全删除 require(...) 部分，然后执行 go mod tidy，我会在 go.mod 中得到以下内容：

require github.com/jinzhu/gorm v1.9.8

只有一个要求。通过这一行，我运行 go build，该模块可以成功构建并运行，没有任何问题。

所以我很困惑 go get -u 在我的模块目录中到底做了什么。

我的两个问题：

• 我应该在模块目录内运行 go get -u 还是可以在模块目录外运行它？

• 为什么go在模块目录外获取-u可以轻松完成？与在模块目录中运行相比，它是否执行相同的下载/升级？

我使用的是最新稳定的golang go1.12.5。因为 go get -u 调用 git 和 git 调用 curl，但 curl 在不稳定的网络上非常糟糕（与 wget 相比）。我无法在模块目录内完成 go get -u 。我会得到很多 error: rpc failed;远端意外挂断；致命的：早期eof；致命：索引包失败；。我不知道这个问题是否有解决方法。但我可以在模块目录之外使用 go get -u 。

（顺便说一句，如果go get可以使用wget，那么它在我的本地环境中就可以工作。我使用wget从来没有任何问题，而且wget在等待很长一段时间后终于完成了下载。但不幸的是，wget不是首选当前开发界的工具）。

解决方案

如果您使用模块，并且希望它实际更新您的 go.mod / go.sum 文件，则需要在模块目录中运行它。

他们的行为非常不同。 go 帮助 get、go 帮助模块-get 和 go 帮助模块 应该解释一些差异，并根据您的情况检查 the module doc：

gorm 的 go.mod 包含很多东西（https://github.com/jinzhu/gorm/blob/master/go.mod），包括它支持的每个可能的数据库的驱动程序，这看起来相当强大。由于您只是做了一个笼统的 -u 并且没有指定 @v1.9.3 或其他什么，它会尝试在模块感知模式下更新所有 Gorm 的依赖项（以及依赖项的依赖项！）。

今天关于《为什么在 golang 模块目录内使用 go get -u 耗时较长，而在 golang 外部则完成得很快？》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！