关于Go依赖查找的疑问：go list与go mod download的依赖差异及间接依赖下载逻辑

我来帮你拆解这两个关于Go模块依赖的常见困惑点，一步步解释清楚：

一、为什么go list比go mod download多返回几个模块？它们是构建必需的吗？ #

首先得明确两个命令的核心定位差异，这是导致结果不同的根本原因：

• go list -m all 会列出整个依赖图谱中出现过的所有模块——不管这些模块是用于主代码构建、测试代码，还是只是某个依赖的测试套件的依赖，甚至是被间接引用但完全没被实际代码用到的模块。它的目标是展示依赖树的完整全貌，而非实际构建需要的子集。
• go mod download 默认只会下载构建目标（这里是go.opentelemetry.io/otel@v1.35.0的生产二进制）实际需要的模块。它会智能跳过那些只在测试代码中被引用、或者在依赖树中存在但没有任何主代码（非测试）依赖的模块。

针对你发现的3个未被下载的模块，具体原因如下：

• github.com/kr/pretty：大概率是github.com/kr/text的测试代码依赖（比如text包的测试用pretty来格式化输出结果），但kr/text的主运行代码完全不需要它。所以构建otel主二进制时，这个模块毫无用处，go mod download就不会下载它，但go list会把它纳入依赖图谱的完整列表。
• github.com/rogpeppe/go-internal：这个模块多是Go工具链内部的辅助库，可能是某个依赖的测试脚本或工具逻辑引用了它，但和otel的生产二进制构建完全无关。
• github.com/stretchr/objx：它是testify的间接依赖，但testify的核心主代码（比如你常用的assert、require包）并不依赖objx——只有testify的某些边缘子包或测试用例才会用到它。所以构建otel时不需要它，自然不会被下载。

结论 #

这三个模块完全不需要用来构建go.opentelemetry.io/otel@v1.35.0的生产二进制，它们只是依赖图谱里的“冗余节点”，仅和测试或非构建场景相关。

二、Go如何处理间接依赖的.mod和.info文件下载？ #

你看源码时可能误解了go mod download的实际逻辑——它并不是只下载直接依赖，而是会递归处理依赖链，但只会下载构建必需的间接依赖。具体流程是这样的：

1. 首先，Go会解析目标模块（这里是otel@v1.35.0）的go.mod文件，获取所有直接依赖列表。
2. 接着，它会下载每个直接依赖的.mod文件，解析这些.mod文件里的依赖项，得到下一层的间接依赖。
3. 然后，Go会执行依赖裁剪操作：只保留那些被目标模块的主代码（或指定构建目标）实际引用的包对应的模块。如果某个间接依赖的模块，没有任何包被主构建目标引用（比如只是测试依赖），就会被直接跳过，不会下载它的.mod、.info或代码文件。
4. 最后，对于剩下的必需间接依赖，Go会下载它们的.mod、.info文件，以及对应的代码（如果构建需要的话）。

举个直观的例子：如果模块A是直接依赖，A的go.mod里声明了依赖模块B，但目标模块的代码从来没引用过B的任何包，那么B就会被裁剪掉，go mod download不会下载B的任何文件。但如果目标模块的代码引用了A的某个包，而A的这个包又引用了B的某个包，那么B就会被判定为必需依赖，进而被下载。

另外，你在go mod download -x输出里看到的.mod文件，其实就是Go在递归解析依赖链时，为了判断后续间接依赖是否必需而临时下载的——它需要先拿到依赖的.mod文件，才能明确这个依赖的依赖项，进而决定是否需要继续递归处理。

内容来源于stack exchange