我真的不明白拥有供应商文件夹的目的。根据我的了解，似乎只有供应商文件夹有用，如果您想使自己的存储库与1.11之前的golang版本兼容。我们正在运行golang 1.12.14。
当我把这个带给我的同事时，他说：
请使用带有模块的供应商-go没有全局工件。这是目前最好的选择，以确保您具有密封的版本并且当有人在其仓库中更改某些内容时代码不会中断。
我认为这是Go模块的作用？我问了这个问题，评论者说我不应该使用供应商？ Does it make sense to add `go mod vendor` to a pre-commit hook?
答案 0 :(得分：6)
Go modules通过将依赖项锁定在go.sum中来保证您可以确定性地构建软件包。话虽如此，只有在将来仍然可以访问依赖项时，确定性地构建项目的承诺才会成立。您不知道会不会是这种情况。
另一方面，无论有没有Go模块，供应商都可以提供更强大的保证，因为它可以在代码旁边提交依赖项。因此，即使无法再访问（删除，重命名等）远程存储库，您仍然可以构建项目。
另一种替代方法是将Go模块与代理一起使用。您可以在official documentation中找到更多信息。您还可以查看一些gomods/athens或goproxy/goproxy之类的OSS实现。如果您不想设置和维护自己的代理，可以在市场上找到一些商业报价。
那么每次提交时都应该go mod vendor吗？好吧，最终取决于您想要的担保种类。但是，是的，利用代理或出售依赖项可以帮助您更接近可复制的版本。
答案 1 :(得分：0)
注意：with Go 1.17、go mod vendor（来自1.17 Go commands）可能更容易使用：
如果主模块指定 go 1.17 或更高版本，go mod vendor 现在使用每个供应商模块在其自己的 vendor/modules.txt 文件中指示的 go 版本注释 go.mod。
从供应商的源代码构建模块的包时使用带注释的版本。
如果主模块指定 go 1.17 或更高版本，go mod vendor 现在省略了供应商依赖项的 go.mod 和 go.sum 文件，否则会干扰 go 命令识别在供应商树中调用时正确的模块根。