go模块离线时不会自动降级，默认直接报错退出，必须手动设置goproxy=direct与gosumdb=off组合开关，并预下载依赖或执行go mod vendor锁定版本，方可实现可靠离线构建。
Go 模块在离线时根本不会自动降级——它默认直接报错退出，必须手动干预缓存和代理行为才能实现“优雅”。
go mod download 离线失败的典型错误
网络断开后执行 go mod download 或 go build，常见报错是：
go: github.com/some/pkg@v1.2.3: Get "https://proxy.golang.org/github.com/some/pkg/@v/v1.2.3.info": dial tcp 142.250.185.113:443: i/o timeout
这不是 Go 的 bug，而是设计使然：Go modules 默认依赖远程源（proxy.golang.org）和校验（sum.golang.org），不连网就卡死。
- 即使本地
pkg/mod/cache里已有该版本，Go 仍会尝试联网验证 checksum 和最新版本信息 -
GOINSECURE对公共模块无效，只影响私有域名 -
go mod verify在离线时必然失败，除非提前关闭校验
启用 GOPROXY=direct + GOSUMDB=off 的组合开关
这是最轻量、最可控的离线方案，适用于 CI 构建、内网开发或临时断网调试：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
GOPROXY=direct：跳过所有代理，直接从模块的go.mod中定义的replace或原始 URL（如 GitHub）拉取 —— 但注意：direct并不意味着“本地缓存优先”，它只是禁用 proxy，仍会尝试 git clone 或 https fetch - 真正起效的是配合
GOSUMDB=off：关掉校验数据库，避免因无法访问sum.golang.org导致失败 - 必须同时设置两者，缺一不可；单独设
GOPROXY=direct仍会因 checksum 校验失败而中断
实操命令示例：
export GOPROXY=direct export GOSUMDB=off go mod download
预热本地 module cache 并锁定版本
离线可用的前提是：所有依赖已完整下载并校验过。靠“运气缓存”不可靠，必须主动固化：
- 在线时运行
go mod vendor，把全部依赖复制进vendor/目录，之后可完全离线构建（需加-mod=vendor） - 或在线执行
go mod download -x（-x 查看实际 fetch 路径），确认$GOPATH/pkg/mod/cache/download/下存在完整.zip和.info文件 -
go.mod中避免使用latest或无版本号的require，否则离线时无法解析具体版本 - 慎用
replace指向本地路径（如replace example.com/a => ./local/a）：离线时它有效，但上线前容易忘记删，引发版本不一致
CI/CD 中稳定离线构建的关键配置
在 GitHub Actions、GitLab CI 等场景下，不能依赖“上一次缓存还在”，必须显式保障：
- 用
actions/cache缓存~/.cache/go-build和$GOPATH/pkg/mod（注意路径随 Go 版本变化） - 构建脚本开头强制设置：
export GOPROXY=direct GOSUMDB=off GO111MODULE=on - 若使用 vendor，检查
vendor/modules.txt是否提交，且go mod vendor -v输出无警告 - 禁止在 CI 中依赖
go get动态拉包——它绕过go.mod约束，离线即崩
复杂点在于：GOSUMDB 关闭后，你得自己确保 go.sum 文件可信且未被篡改；一旦误删或手动生成，离线构建可能引入不一致依赖。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
