go build 和 go run 会自动下载依赖，因为 Go 1.16+ 默认启用 GO111MODULE=on，且项目根目录存在有效 go.mod 文件时，二者按需解析并下载代码实际 import 的模块（非全部依赖），前提是模块已初始化、路径规范、网络可达且 GOPROXY 配置正确。
go build 和 go run 为什么会自动下载依赖
因为 Go 1.16+ 默认开启 GO111MODULE=on，且项目根目录下存在有效的 go.mod 文件时，go build 和 go run 就会触发模块解析和按需下载——不是“所有依赖都拉一遍”，而是只下载当前构建路径实际用到的模块版本。
常见错误现象：执行 go build 没反应、没报错也没下载，大概率是项目还没初始化为模块（缺 go.mod），或当前目录不是模块根（比如误在子目录里执行命令）。
- 必须先运行
go mod init example.com/myapp，模块名不一定要真实可访问，但不能是空字符串或含非法字符 -
import语句必须出现在 .go 源文件中，且该包未在标准库内；仅写在注释里、或用_导入但未实际调用函数，仍会触发下载 - 如果某包被
import但代码里完全没用到它（比如没调任何符号），Go 会把它标记为// indirect，但仍会下载其最小兼容版本
require 行到底控制什么，又不控制什么
require 只存在于 go.mod 文件中，它声明的是“我直接依赖这个模块”，但不等于“构建时就一定用这一版”——最终加载哪个版本，由整个模块图的最小版本选择（MVS）算法决定。
容易踩的坑：手动改 require github.com/sirupsen/logrus v1.8.0 成 v1.9.0 后直接编译，结果还是旧版。这是因为 require 变更本身不会触发下载或校验。
立即学习“go语言免费学习笔记（深入）”；
- 改完
require行后，必须跟go mod download或再次go get github.com/sirupsen/logrus@v1.9.0才生效 -
replace和exclude会覆盖require的效果：replace改路径，exclude删版本，两者优先级都高于require -
go list -m all输出的是“声明依赖图”，不是“实际加载版本”；要看真正用哪版，得查go list -m -f '{{.Version}}' github.com/sirupsen/logrus
go mod download all 是真·全量下载吗
是，但有边界：go mod download all 会下载 go list -m all 列出的所有模块，包括 // indirect 依赖，但它跳过三类东西：被 replace 指向本地路径的模块、vendor 目录里的模块、以及被 exclude 显式剔除的版本（只要还在模块图里，仍会被下）。
CI 环境里常用它预热缓存，但别以为下了就能离线构建成功——cgo、//go:embed、或不同 build tag 分支下的模块，可能根本不在 go list -m all 范围内，构建时仍会触发网络请求。
- 运行前务必先
go mod tidy，否则go.mod里漏掉的间接依赖不会被all拉到 - 若某模块
go.sum校验失败（比如手动改过 checksum），go mod download all会直接退出，不跳过 - 想验证是否真离线可用，得设
GOPROXY=direct+GOSUMDB=off，再跑一次go build -v -a ./...，看有没有新出现Fetching日志
依赖传递带来的版本“隐形切换”问题
当你 import A，A 依赖 B v2.0，而你自己又单独 require 了 B v1.5，Go 不会报错，而是用 MVS 算法选一个满足双方约束的版本（比如 v1.7）。你只看 go.mod 里的 require 行，根本意识不到 B 已被“悄悄升级”。
这种隐性升级最常发生在测试或调试阶段：本地 go run 没问题，CI 构建却失败，往往是因为某间接依赖的 API 在小版本间发生了破坏性变更，而你的 go.mod 没显式锁定它。
- 查清实际版本：用
go list -m -u -f '{{.Path}} {{.Version}} {{.Indirect}}' all，重点关注true标记的间接依赖 - 强制锁定间接依赖：加一行
require github.com/some/indirect v1.2.3，再go mod tidy，它就会从// indirect变成直接声明 - 别依赖
go get -u ./全局升级——它只升直接依赖，间接依赖仍走 MVS，结果不可控
