go mod download在断网时失败，是因为默认启用模块校验机制，必须同时设置GOPROXY=direct、GOSUMDB=off和GO111MODULE=on，否则仍会尝试联网访问proxy.golang.org和sum.golang.org；断网构建前提是在有网环境完成go mod vendor或完整缓存依赖。
为什么 go mod download 在断网时会失败
默认情况下，go mod download 会尝试连接远程代理（如 proxy.golang.org）或模块源（如 GitHub），校验模块 checksum、验证 go.sum 一致性，并检查 module path 是否存在。断网时这些网络请求直接超时或报错，例如：Get "https://proxy.golang.org/...": dial tcp: lookup proxy.golang.org: no such host。
关键不是“下载”本身失败，而是 Go 默认开启的多项校验强制依赖网络——即使你本地已有完整 vendor/ 或缓存模块，它仍要联网确认。
关闭校验的三个必要开关
必须同时设置以下环境变量，缺一不可：
-
GOPROXY=direct：跳过代理，避免尝试连接proxy.golang.org或私有代理 -
GOSUMDB=off：彻底禁用 checksum 数据库校验，否则go mod download仍会尝试访问sum.golang.org -
GO111MODULE=on（确保启用模块模式，尤其在 GOPATH 模式下容易被忽略）
注意：GOSUMDB=off 是最常被遗漏的一环——很多用户只设 GOPROXY=direct，结果仍卡在 verifying github.com/xxx@v1.2.3: checksum mismatch。
断网编译前的实操准备
仅关闭校验还不够。Go 编译器仍需能读取所有依赖源码，所以必须提前完成两件事：
- 在有网时运行
go mod vendor，把全部依赖拉到vendor/目录；或确保$GOPATH/pkg/mod中已缓存所需版本（可用go mod download -x查看实际 fetch 路径） - 确认
go.mod中无 replace 指向本地不存在的路径，否则断网后go build会报cannot find module providing package - 若使用
vendor/，建议加-mod=vendor参数显式指定，例如：go build -mod=vendor ./cmd/app
不推荐依赖 go mod download 断网执行——它本质仍是“下载”，而断网场景真正可靠的是 go build -mod=vendor 或利用本地 module cache。
验证是否真能离线工作
关掉 Wi-Fi / 拔掉网线后，运行以下命令测试：
GO111MODULE=on GOPROXY=direct GOSUMDB=off go build -mod=vendor -o app ./cmd/app
如果失败，常见原因：
-
go: downloading ...日志出现 → 说明仍有模块未缓存或 vendor 不全，回退补全 -
invalid version: git ls-remote→ 某个依赖用了replace指向 Git 仓库，且未提前git clone到本地 -
no required module provides package→go.mod中 indirect 依赖未被 vendor 收录，需手动go mod vendor或加-mod=readonly排查缺失项
断网构建的稳定边界很窄：它只保证“已有代码能编译”，不解决缺失依赖、Git 替换、动态生成代码等场景。真正可靠的离线方案，永远始于一次完整的联网预处理。
