虽然如此，我认为某种查询语言也非常有用，但这两个功能可以并且应该共存。而且对于查询语言存在于第三方工具中也是可以接受的。

这个语法有点复杂。对于单条路径，输出可以仅仅是沿着路径的节点(包)。对于完整的导入子图，我们可能需要一种方法来显示边。
但是我想go mod graph已经有一种表示边的方式了......

我最初的想法是将换行符分隔的输出扩展为可能包含许多空行分隔组的形式：

$ go mod why baz
foo
bar
baz

foo
some-other-bar
baz

另一种选择可能是利用 go mod graph 边缘格式，这样我们只需显示到达目的地的所有路径的子图：

$ go mod why baz
foo bar
bar baz
foo some-other-bar
some-other-bar baz

我个人更喜欢第一种，因为我觉得它更容易被人类理解。

我认为在一般情况下，组是不可行的：即使忽略循环(在构建约束下是可能的),在最坏的情况下，唯一路径的数量与节点数量成指数关系。

那么，或许答案是提供一个 go mod graph ,它输出的是包导入图，而不是模块依赖关系图。然后，可以根据需要进行可视化、查询或检查。
可以通过 go list -deps -json all 获取这些信息，但需要更多的工作。任何目前理解 go mod graph 输出的工具都可以轻松地开箱即用。

额外的思考 - go mod graph 的包变体应该接受通常的构建标志和参数。为了示例的目的，使用 go-pkg-graph 作为占位符：

# the entire graph for all packages here
go-pkg-graph ./...

# only the sub-graph with the current main package at its root
go-pkg-graph

# same as the above, but with different build params
GOOS=windows go-pkg-graph -tags=purego