Go的pkg/mod/cache目录下包无提取源码是否说明未被编译进二进制？

你提出的猜测完全成立，如果某个第三方依赖仅在go/pkg/mod/cache/download目录下存在模块文件，没有在go/pkg/mod/$module@$version下生成对应的解压源代码目录，说明该依赖的代码没有被编译进你当前构建的Go二进制文件。

原理说明 #

Go工具链的构建流程分为两个独立阶段，和你观察到的缓存目录行为完全对应：

• 第一阶段是依赖图解析流程：执行go build时，Go会首先拉取所有直接、间接依赖的.mod文件存储到go/pkg/mod/cache/download目录，用来计算最终使用的依赖版本树。这一步只需要各个模块的依赖声明信息，不需要源代码，因此大量仅参与依赖版本计算的模块，只会在这个目录下留下.mod文件，不会下载源码压缩包。
• 第二阶段是实际编译流程：只有被你的业务代码直接或间接import的包所属的模块，Go工具链才会下载对应版本的模块源码压缩包，解压到go/pkg/mod/$module@$version目录下，再将对应包的代码编译、链接到最终的二进制文件中。

常见的仅拉取.mod文件的依赖场景 #

很多模块只会参与依赖图计算，不会触发源码下载，常见情况包括：

• 是其他模块的可选依赖，没有被实际用到的代码路径引用
• 仅在某个依赖的测试代码中被引用，业务构建不会触发测试依赖的源码拉取
• 是依赖图计算过程中被更高版本替代的旧版本模块，仅用来做版本冲突校验

验证方法 #

你可以执行以下命令对比验证逻辑：

1. 执行go list -m all，输出的是所有参与依赖图计算、已经拉取了.mod文件的模块列表
2. 执行go list -deps ./...，输出的是所有实际参与当前项目构建的包所属的模块列表
   两者的差集就是那些仅拉取了.mod文件、没有被编译进二进制的模块。

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