为何`go list -m all`返回模块数多于go.mod中声明的依赖？

问题描述 #

我有一个简单Go模块，仅依赖外部模块github.com/spf13/viper v1.15.0，其go.mod文件内容如下：

module github.com/me/mymodule

go 1.20

require github.com/spf13/viper v1.15.0

require (
    github.com/fsnotify/fsnotify v1.6.0 // indirect
    github.com/hashicorp/hcl v1.0.0 // indirect
    github.com/magiconair/properties v1.8.7 // indirect
    github.com/mitchellh/mapstructure v1.5.0 // indirect
    github.com/pelletier/go-toml/v2 v2.0.6 // indirect
    github.com/spf13/afero v1.9.3 // indirect
    github.com/spf13/cast v1.5.0 // indirect
    github.com/spf13/jwalterweatherman v1.1.0 // indirect
    github.com/spf13/pflag v1.0.5 // indirect
    github.com/subosito/gotenv v1.4.2 // indirect
    golang.org/x/sys v0.3.0 // indirect
    golang.org/x/text v0.5.0 // indirect
    gopkg.in/ini.v1 v1.67.0 // indirect
    gopkg.in/yaml.v3 v3.0.1 // indirect
)

执行go list -m all命令后，得到的模块列表远长于go.mod中的声明，例如包含：

cloud.google.com/go v0.105.0
cloud.google.com/go/bigquery v1.8.0
cloud.google.com/go/compute v1.14.0
cloud.google.com/go/compute/metadata v0.2.3
cloud.google.com/go/datastore v1.1.0
cloud.google.com/go/firestore v1.9.0
cloud.google.com/go/longrunning v0.3.0
cloud.google.com/go/pubsub v1.3.1
cloud.google.com/go/storage v1.14.0

执行go mod why -m cloud.google.com/go时，返回结果为：

main module does not need module cloud.google.com/go

请问造成这种差异的原因是什么？

原因分析 #

核心原因是**go list -m all会列出本地模块缓存中所有与当前模块依赖链存在关联（包括历史关联）的模块，而非仅当前构建必需的模块**，具体细节如下：

• Go的模块缓存是全局共享的，这些额外的模块可能是你之前在其他本地项目中下载的，或是Viper依赖的某个模块在历史版本中引入过，但当前Viper使用的版本已不再依赖它们。go list -m all会扫描缓存中所有和当前模块依赖树有交集的模块，哪怕是过时的交集。
• go mod why的结果明确证明这些模块并非当前项目构建所必需，Go工具链不会将它们纳入最终构建列表，因此不会出现在go.mod中。go.mod仅记录当前构建必需的直接/间接依赖，以及为解决版本冲突保留的模块，不会包含缓存中无关的历史模块。
• 另一种可能是你之前执行过go get等命令拉取过这些模块，它们被留在缓存中，go list -m all会将其纳入结果。

验证方法 #

如果要确认这一点，可以执行以下步骤：

1. 清空全局模块缓存：

go clean -modcache

2. 重新拉取当前项目的依赖：

go mod tidy

3. 再次执行go list -m all，此时结果会与go.mod中的依赖链一致，那些无关模块会消失。

内容的提问来源于stack exchange，提问作者Picci