要与模块一起工作，像goimports这样的工具应该了解模块缓存中的一组模块。然后，它可以建议尚未在go.mod中要求或由包或其依赖项导入的包。至少，它应该能够列出用户模块缓存中每个模块的最新版本。(如果GOPROXY设置了，它应该能够列出代理提供的模块的最新版本。)
目前，似乎没有一种方法可以让像goimports这样的工具在不猜测模块缓存目录(该目录正在更改：golang.org/cl/126755)并然后遍历目录的情况下，建议当前模块的传递性模块依赖项之外的包。目录布局似乎可能是稳定的，但找到目录有点棘手。我们还需要手动处理goproxy。
go/packages一直在使用go list来查找有关包的元数据，因此理想情况下，我们可以使用go list或者也许go mod来获取这些信息。但也许有更好的方法来获取它。
9条答案
按热度按时间lrpiutwd1#
请问一个快速问题，因为我不太清楚我认为这里的答案应该是什么样的。
在模块(以及它包含的软件包)存在多个主要版本的情况下，你希望
goimports如何回应？在我看来，由于模块的存在，
goimports的工作空间似乎大大增加了。一个折中的起点是否是让
goimports能够与go.mod引用的模块一起工作？kcrjzv8t2#
问题在于，这比现有的体验要差得多。
目前，如果你开始一个新的项目，你会创建一个新的目录并输入一些代码。当你运行goimports时，它会看到你曾经使用过的所有包，并根据这些包选择你的导入，这很可能包含你想要的包，因为大多数人在使用类似的包进行类似的工作。你也很可能使用go get来查看你想要做的一些示例，这也会为搜索空间做好准备。
在模块的世界里，所有这些信息都会消失，每个新模块都从没有导入开始，所以goimports对你来说没有任何作用。
搜索空间并不大，你完全不需要担心次要版本，你只需要知道哪些导入路径在模块缓存中有条目，如果导入被添加到文件中，你会检查mvs会添加什么版本，因为这就是你要做的事情。goimports永远不会为你编写模块文件。
主要版本也是同样的问题，如果你无论如何都要将模块检出到你的go路径，go imports现在就会面临这个问题：两个同名的不同包，选择最好的一个，这是它已经需要做的事情。当我们有多个完全匹配的候选项时，我们可能需要添加一些逻辑来偏向较大的主要版本，但即使你仍然在使用GOPATH而不是模块缓存，我们也需要这样做。
zbsbpyhn3#
是的，正如@ianthehat所说，仅使用从
go.mod引用的模块的goimports将对用户造成重大回归。据我了解，在几乎所有方面，不同版本的主要模块都被视为不同的模块。而goimports可能希望添加一些启发式方法，当两者都在模块缓存中时，可能会倾向于选择较晚的主要版本，但这主要与模块的分支或(在GOPATH世界中)包的分支问题相同。
bvjveswy4#
(相关 #24661 )
fv2wmkja5#
#26718 是否涵盖了所有已知的使用案例，还是还有其他？
vql8enpb6#
CC @heschik
slwdgvem7#
#32337建议
GOPROXY=off作为一种方法，我们可以让用户明确请求仅使用模块缓存中的内容来解析软件包和/或模块版本。xv8emn3q8#
#43646 建议添加
GOPROXY=cache以实现与GOPROXY=off不同的行为。xam8gpfp9#
请注意，模块缓存的目录结构在官方文档中有记录：https://go.dev/ref/mod#module-cache。我们能否将其解释为某种稳定性保证？