go mod download 默认将包下载到 $GOMODCACHE（即 $GOPATH/pkg/mod 或 $HOME/go/pkg/mod），全局共享，不放入项目目录或 vendor/；它只下载并验证依赖，不修改 go.mod 或 go.sum。
go mod download 会把包下到哪儿？
它默认下载到 $GOPATH/pkg/mod，不是项目目录里，也不是 vendor/。这个路径是全局共享的——同一台机器上所有 Go 项目共用这一份缓存。
- 如果你改过
GOPATH，那实际路径就是$GOPATH/pkg/mod - 如果没设
GOPATH（Go 1.16+ 默认行为），它会 fallback 到$HOME/go/pkg/mod - 想确认当前位置？运行
go env GOPATH和go env GOMODCACHE，后者才是真实缓存根目录
别手动删 pkg/mod 下的子目录，容易破坏校验和；真要清理，用 go clean -modcache。
不加参数直接跑 go mod download 会发生什么？
它会读取 go.mod，把里面所有 require 声明的模块（包括间接依赖）全部拉下来，但不会解压源码到项目目录，也不生成 vendor/。
- 它只做“下载+验证”，不构建、不编译、不检查
go.sum是否匹配（那是go build或go list干的事） - 如果某个依赖在
go.sum里有记录但网络不可达，go mod download会失败，报错类似：verifying github.com/some/pkg@v1.2.3: checksum mismatch - 想跳过校验？不行。
go mod download强制校验，这是安全底线
常见误操作：以为执行完它就能离线 build——其实可以，但前提是所有依赖都已完整下载且校验通过；如果 go.mod 里有 // indirect 依赖没被显式 require 过，也可能漏下。
立即学习“go语言免费学习笔记（深入）”；
怎么只下载某一个包或特定版本？
用 go mod download <module>[@<version>]</version></module>，比如：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
go mod download golang.org/x/net（最新 tagged 版本） -
go mod download golang.org/x/net@v0.14.0（指定版本） -
go mod download golang.org/x/net@master（注意：这其实是 pseudo-version，不是 git 分支名）
要点：
- 模块路径必须和
go.mod里声明的一致，大小写、斜杠都不能错 - 如果指定的版本不存在（比如拼错 tag 或 commit hash 不合法），命令会报
unknown revision - 它不会自动更新
go.mod或go.sum，只是把包放进缓存；后续go build时才会触发写入go.sum
别用这个命令来“试装”新版本——它不改变依赖图，也不会帮你解决兼容性问题。
CI 环境里要不要跑 go mod download？
要看你的缓存策略。如果 CI 能复用 GOMODCACHE（比如用 Docker layer 缓存或对象存储挂载），那值得跑；否则纯浪费时间。
- 多数云 CI（GitHub Actions、GitLab CI）默认不保留
GOMODCACHE，每次都是空缓存，这时go mod download只是提前暴露网络问题，对加速构建帮助有限 - 真正影响速度的是
go build阶段的 module lookup，而它本身就会触发按需下载；go mod download提前做，只是把耗时前置，并不减少总下载量 - 更关键的是：如果 CI 里
go.mod和本地不一致（比如忘了go mod tidy），go mod download会下错包，反而掩盖了依赖不一致的问题
所以重点不在“下不下”，而在“go.mod 和 go.sum 是否真实反映当前所需”。校验这一步比预下载重要得多。
有些细节藏得深：比如 go mod download 对 replace 和 exclude 的处理是即时生效的，但它不会告诉你某个 replace 目标根本不存在——直到 build 阶段才爆红。
