go mod download 使用当前 PATH 中 which go 返回的 go 可执行文件版本，与 go.mod 声明的版本无关；它只下载 go.mod 明确列出的依赖（含间接依赖），忽略 replace 远程 URL 的条目，缓存存于 $GOPATH/pkg/mod，多版本共用同一缓存。
go mod download 用的是哪个 go 版本？
它用的是当前 shell 中 which go 返回的那个可执行文件，不是 go.mod 里声明的 go 1.26。也就是说，go mod download 的行为完全由你 PATH 里排在最前面的 go 决定，和项目声明的 Go 版本无关。
常见错误现象：go mod download 报错 go: unsupported version 1.26.2，其实是当前 PATH 里的 go 太旧（比如系统自带的 1.19），根本解析不了新语法；或者反过来，用新版 go 下载依赖后，旧版 go 编译时报 invalid module version，因为缓存里混进了高版本生成的模块数据。
- 验证方式：运行
which go和go version，确认是否是你想用的版本 - 临时切换：直接调用完整路径，比如
/usr/local/go-1.26.2/bin/go mod download - 别依赖别名或函数封装——IDE 或 CI 脚本通常不继承 shell 函数，只认 PATH
go mod download 会下载哪些依赖？
它只下载 go.mod 中明确列出的依赖（含 transitive 间接依赖），但跳过所有 replace 指向远程 URL 的条目，例如：replace example.com/a => https://github.com/x/a v1.2.0。Go 认为这是“构建时才需解析”的重定向，download 阶段直接忽略。
使用场景：CI 构建前预热模块缓存、离线环境打包、排查依赖拉取失败原因。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 若想强制包含 replace 的远程目标，得用
go build -v -a ./...触发真实 fetch -
go mod download -json可输出结构化结果，方便脚本解析 - 依赖实际存放在
$GOPATH/pkg/mod，不同 Go 版本共用同一缓存目录，没有隔离
多版本共存时 GOPROXY 和 GOSUMDB 怎么设？
这两个环境变量是全局生效的，和具体用哪个 go 命令无关。只要它们被设了，所有版本的 go 都会遵守——包括 go1.25.8、go1.26.2 等包装器。
容易踩的坑：在某个终端临时 export GOPROXY=direct，然后运行 go mod download，结果发现其他终端里 go build 也变慢了，因为 GOPROXY=direct 已被写入 shell 初始化文件或被 IDE 继承。
- 推荐做法：统一在
~/.bashrc或~/.zshrc中设置，避免临时 export - 私有模块必须配
GOPRIVATE=*.corp.example.com，否则即使GOPROXY=direct也会尝试走代理校验 sum -
GOSUMDB=off才能彻底跳过校验；GOSUMDB=off+GOPROXY=direct是离线开发唯一可靠组合
IDE 里依赖下载失败，是不是版本没切对？
很可能是。VS Code 或 GoLand 启动时读取的是登录 shell 的 PATH，不是你当前终端里刚 export PATH=... 的临时值。哪怕你 which go 看着是对的，IDE 里 go mod download 仍可能调用旧版本。
最易被忽略的一点：重启 IDE 后，还要确认其设置里没有硬编码 GOROOT。有些老插件会绕过 PATH，直接读 GOROOT 下的 bin/go，而这个路径可能指向一个已卸载的旧版本。
- VS Code：检查
Go: Locate Tools输出，看它实际调用的go路径 - GoLand：Preferences → Languages & Frameworks → Go → GOROOT，确保为空或指向你当前主版本
- 别图省事把多个
go/bin目录都塞进 PATH——which go结果不可控，IDE 更容易选错
