对于我的项目，我试图获取项目的所有依赖项和子依赖项。我需要每个依赖项的特定版本。不仅需要项目的依赖项，还需要依赖项的依赖项，依此类推直到根。
对于我的项目，go list -m all适用于除未选择使用go.mod文件的间接依赖项之外的所有内容。现在，我的工作流正在获取第一批存储库，从git下载它们，然后使用“ GO111MODULE = on build./…”。和“ GO111MODULE =执行列表-m -json全部”以获取依赖项列表。我不检查go.mod，因为我正在扫描的所有存储库都在使用go.mod文件。
对于这个初始列表中的依赖项列表，我有一些疑问，对于没有go.mod文件的文件，我将其用作参考：“ https://blog.golang.org/using-go-modules”
-Path =从go list -m all接收，它可以是GitHub，gopkg或用于dl go软件包的任何东西。
没有go.mod
-“GO111MODULE=on go mod init <PATH from parent go.mod>”
-“GO111MODULE=on go build ./…”
-“GO111MODULE=on go mod tidy”
-“GO111MODULE=on go list -m -json all”
-From there I get a list of the dependencies of this module.
使用go.mod
-“GO111MODULE=on go build ./…”
-“GO111MODULE=on go mod tidy”
-“GO111MODULE=on go list -m -json all”
我应该在每个具有go.mod文件的依赖项上运行go build吗？对于没有go.mod文件的文件，我知道应该这样做，因为否则我们将如何用依赖项填充go.mod文件。但是对于带有go.mod文件的文件，我是否会提取那些我的项目不一定要通过go build使用的额外内容，例如测试文件和其他在我仅导入该项目时可能不会使用的文件？我知道获得更多未使用的依赖关系而不是丢失一些依赖关系是更好的选择，但是对于如此庞大的依赖关系量来说，这有点让人不知所措。
答案 0 :(得分：0)
我可以尝试分析go.sum文件（当您执行go list -u时，go.sum已创建）
go命令使用go.sum文件来确保这些模块的后续下载与第一次下载时检索的位相同，以确保您的项目所依赖的模块不会发生意外更改，无论是恶意，意外还是其他原因。应该将go.mod和go.sum都检查到版本控制中。 （Using Go Modules - Adding a dependency）
go.sum文件列出了模块所需的直接和间接依赖性的校验和（和版本标记）。
% cat go.sum
...
github.com/bmizerany/perks v0.0.0-20141205001514-d9a9656a3a4b/go.mod h1:ac9efd0D1fsDb3EJvhqgXRbFx7bs2wqZ10HQPeU8U/Q=
github.com/c2h5oh/datasize v0.0.0-20171227191756-4eba002a5eae/go.mod h1:S/7n9copUssQ56c7aAgHqftWO4LTf4xY6CGWt8Bc+3M=
github.com/cespare/xxhash v1.1.0/go.mod h1:XrSqR1VqqWfGrhpAt58auRo0WTKS1nRRg3ghfAqPWnc=
github.com/client9/misspell v0.3.4/go.mod h1:qj6jICC3Q7zFZvVWo7KLAzC3yx5G7kyvSDkc90ppPyw=
github.com/cockroachdb/apd v1.1.0/go.mod h1:8Sl8LxpKi29FqWXR16WEFZRNSz3SoPzUzeMeY4+DwBQ=
...
答案 1 :(得分：0)
不幸的是，“所有依赖项”这句话含糊不清。
go list -m 列出所选版本由您的 go.mod 文件确定的所有模块。这是“所有依赖项”的一个可能定义，但它是一组比我认为大多数人在谈论模块的“依赖项”时想要的更广泛的模块。
实际上，go list -test all（没有 -m 标志）是我通常关心的最广泛的依赖项集：它包括模块中 import 语句中列出的所有包（即在模块中运行 go test ./... 所需的一切），加上在这些包上运行 go test 所需的所有包。
（特别是，go list -test all 也是运行 go mod tidy 时将解析的包集。）