问题描述
给出一个Golang（1.14+）中的项目，该项目正在使用测试依赖项（例如github.com/stretchr/testify），现在假定该项目是一个可供其他人使用的公共库。
通常，当我现在使用go mod graph时，总是会看到这种依赖性：
github.com/its-me/my-great-library@1.0.0
github.com/stretchr/testify@v1.6.1 github.com/davecgh/go-spew@v1.1.0
github.com/stretchr/testify@v1.6.1 github.com/pmezard/go-difflib@v1.0.0
github.com/stretchr/testify@v1.6.1 github.com/stretchr/objx@v0.1.0
github.com/stretchr/testify@v1.6.1 gopkg.in/yaml.v3@v3.0.0-20200313102051-9f266ea9e77c
gopkg.in/yaml.v3@v3.0.0-20200313102051-9f266ea9e77c gopkg.in/check.v1@v0.0.0-20161208181325-20d25e280405
go mod tidy或go mod download似乎也从使用的库中下载了所有测试依赖项。但是，除了告诉所有人在其exclude文件中使用go.mod之外，还有没有办法阻止这种情况的导出？
解决方法
go mod tidy 旨在提供运行 go test all 所需的所有依赖项。请注意，在 Go 1.16 中，go test all 对测试的传递依赖项 (https://tip.golang.org/doc/go1.16#all-pattern) 的积极性将有所降低。
但是，如果您自己的测试本身使用的是 testify，那么您的软件包的用户将需要下载 testify 才能在他们的系统中运行 go test all自己的模块。
（正如 colm.anseo 所指出的，如果您愿意，您可以将较重的测试拆分到一个单独的包中，这样当您的用户运行 go test all 时，他们将不会运行这些测试，也无需下载源代码这些依赖项的代码。）
就目前而言，您模块的用户最终会以任何一种方式下载 go.mod 模块的 testify 文件：传递模块依赖项必须保持一致。一项计划中的“延迟加载”功能将使它甚至不再需要 go.mod 文件以用于其他不相关模块的传递依赖项（有关详细信息，请参阅 https://golang.org/issue/36460）。
您应该考虑的一般事项： 如果您在模块内部具有测试依赖项，则应该不能排除它们。
为什么？
因为如果您的测试依赖项的1.7.2版导致测试失败，该怎么办？但是1.7.1很棒。而且测试依赖项的2.0.1版甚至无法编译，因为API已更改？
模块的目标是在不同的计算机上具有相同的行为。如果排除测试依赖项，则不能确定模块的测试结果是否相同。对于内部软件包，这是可以的，但对于公共图书馆则不能。当您尝试隐藏参与者时，如何确保他们使用相同的版本？隐藏测试依赖项时，如何使用CI测试更改？
我也不喜欢具有成千上万个依赖项的项目，但是唯一的解决方案是不使用太多的第三包。在Go中，编译器会忽略测试依赖项，因此不会影响二进制文件的大小。因此，它并没有像其他一些语言那么严重。