我刚刚继承了一个Go语言项目。Mod文件缺少声明的依赖项，但依赖项在运行中。和文件:
...
cloud.google.com/go/storage v?.?.? <- this is the missing entry in go.mod
...
这些是go中的条目。和文件:
...
cloud.google.com/go/storage v1.0.0/go.mod h1:<some hash>
cloud.google.com/go/storage v1.5.0/go.mod h1:<some hash>
cloud.google.com/go/storage v1.6.0/go.mod h1:<some hash>
cloud.google.com/go/storage v1.8.0/go.mod h1:<some hash>
cloud.google.com/go/storage v1.10.0 h1:<some hash>
cloud.google.com/go/storage v1.10.0/go.mod h1:<some hash>
...
我的问题是:
- 为什么一开始就有5个版本。和文件?
- 如果有其他库依赖于这些特定的版本，所有5被编译成二进制文件?
- 哪个版本的库将链接到我的应用程序代码，因为依赖关系没有声明?
我试图在Go文档中找到解释，但无法找到，感谢任何帮助。
这些依赖项很可能是可传递的依赖项，也就是您所依赖的包的依赖项(或者它们所依赖的包的依赖项，等等)。的走了。Sum包含模块的所有依赖项的行，直接的或其他的，以便构建是可复制的。
来自Go博客:
除了去。Mod, go命令维护一个名为go的文件。包含特定模块版本内容的预期加密哈希值的总和
…
go命令使用go。Sum文件，以确保这些模块的未来下载检索与第一次下载相同的位，以确保您的项目所依赖的模块不会意外更改，无论是恶意的，意外的，还是其他原因。都走了。装好就走。Sum应该检入版本控制。
被包含的包的版本取决于go。您所依赖的包的Mod文件。您可能依赖于几个包，每个包可能依赖于依赖项的不同版本。
它们是否最终出现在您的构建中取决于包含它们的依赖项是否被编译到二进制文件中。例如，测试文件/包通常依赖于测试库及其依赖项。这些都不会包含在您的go build可执行文件中。
您可以像这样检查将包含在构建中的包列表:
go list -m all
你应该只是以防万一运行go mod tidy来删除任何实际上不再需要的依赖项。