Go构建时“重新下载部分包”通常并非真实联网下载，而是因模块缓存未命中、go.mod或go.sum变更、replace路径更新等触发本地模块加载或校验重计算。
Go 构建时“重新下载部分包”，通常不是真正从网络重下，而是 模块缓存未命中或本地依赖状态变更触发了重新解析与加载。根本原因在于 Go 的模块依赖管理机制（尤其是 go.mod 和 go.sum）与构建缓存（$GOCACHE）是两套独立系统，各自有不同触发条件。
模块缓存（$GOPATH/pkg/mod）决定是否需要“下载”
Go 不会在每次构建时都联网下载——它优先查本地模块缓存。所谓“重新下载”，其实是：
- 该模块版本在本地缓存中不存在（比如首次使用某版本、手动清过
pkg/mod） - 运行了
go get -u或修改了go.mod导致依赖树变动，触发新版本拉取 - 模块路径被替换（如
replace指向本地目录），但该目录内容更新后，Go 会基于校验和判断是否需重新“加载”（表现为类似下载的日志） - 使用了
go mod download显式刷新，或GO111MODULE=on go build在无缓存环境下首次执行
go.sum 变更会强制验证，可能触发重获取
go.sum 记录每个模块的校验和。如果：
- 你手动修改了
go.sum，或go mod tidy自动更新了它 - 某个间接依赖的校验和不匹配（例如源仓库篡改、镜像源不一致）
Go 会拒绝构建，并尝试重新下载对应模块以重新计算校验和——日志里就显示 “downloading …”，容易被误认为“重复下载”。
构建缓存（$GOCACHE）不影响下载，但影响编译速度
$GOCACHE 存的是编译中间产物（如已编译的包对象），和模块下载无关。即使 $GOCACHE 命中，只要模块文件没在 pkg/mod 里，Go 仍会先确保模块存在——所以你会看到“download”日志，但实际可能是毫秒级的本地文件复制（尤其用 GOPROXY=direct 时）。
常见“假重下”场景与应对
以下情况看似在重下，实则合理或可优化：
-
CI/CD 环境每次清空
pkg/mod：建议复用模块缓存（如 Docker layer 缓存$GOPATH/pkg/mod） -
切换分支后
go.mod变了：这是预期行为，Go 必须同步依赖状态 -
用了
replace指向../xxx，但没go mod edit -replace而是直接改代码：Go 无法感知本地改动，下次构建会重新加载整个模块 -
设置了
GOPROXY=off：完全禁用代理和校验，可能反复尝试 fetch（不推荐）
基本上就这些。Go 的设计是“确定性优先”：宁可多走一遍检查，也不容忍依赖不一致。理解 pkg/mod（下载/存储）、go.sum（验证）、$GOCACHE（编译加速）三者的分工，就能分清哪些“下载”真耗时，哪些只是日志干扰。
