必须在联网机执行go mod download all，离线机无法运行该命令；需同步设置goproxy=direct和gosumdb=off，并完整拷贝$gopath/pkg/mod目录（保留@vx.y.z结构）及go.sum文件。
go mod download all 必须在联网机执行
离线环境本身无法执行 go mod download，它会卡在 proxy.golang.org: no such host 或直接超时。真正有效的做法是：在能联网的机器上，用目标项目的 go.mod 运行 go mod download all —— 注意是 all（关键字，不是通配符），否则只下直接依赖，间接模块仍会在离线构建时触发网络请求。
常见错误是只跑 go mod download，结果 go build 时突然报 Fetching github.com/sirupsen/logrus@v1.9.3。验证是否完整：执行 go list -m all | wc -l，再对比 ls $GOPATH/pkg/mod/cache/download/ | wc -l，两者应基本一致（忽略 replace 和 vendor 内模块）。
-
go mod download all不检查代码能否编译，只管下载；哪怕某个模块被exclude了，只要go list -m all能列出来，它就会下 - 若项目含
//go:embed或 cgo，go list -m all可能漏掉部分隐式依赖，需加-a参数构建一次观察实际 fetch 行为 - 别信“只复制 vendor 目录就行”——
go mod vendor不下载任何新模块，它只搬运本地缓存里已有的东西
打包 pkg/mod 时必须保留完整目录结构
离线机要能识别模块，靠的是 Go 对 $GOPATH/pkg/mod 下路径的硬编码解析规则，比如 github.com/go-sql-driver/mysql@v1.14.0 必须解压成 github.com/go-sql-driver/mysql@v1.14.0 子目录，不能扁平化、不能改名、不能漏掉 @vX.Y.Z 后缀。
错误示例：用 cp -r ~/go/pkg/mod/* ./mod-cache/ 导致路径丢失，或用 zip 工具压缩时启用“相对路径压缩”导致解压后多一层父目录。正确做法是 tar 打包时指定 -C $GOPATH/pkg mod，解压时也用 -C $GOPATH/pkg。
- 确保离线机的
$GOPATH与打包机一致；若不一致，手动修改解压路径，或设export GOPATH=/your/path后再解压 - 私有模块若走 GitLab/GitHub Enterprise，其域名必须提前加入
GOINSECURE，否则 TLS 验证失败会被误判为 checksum mismatch - Windows 用户注意：路径含空格或中文会导致
go mod download解析失败，建议统一用英文短路径
GOPROXY=direct + GOSUMDB=off 是离线构建的硬性开关
即使所有模块文件都在本地，Go 默认仍会尝试连接 sum.golang.org 校验哈希，或向 proxy.golang.org 查询模块索引。这两个行为必须显式关闭，否则构建失败不是因为“找不到包”，而是卡在校验阶段。
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
设置方式：在离线机构建前运行 go env -w GOPROXY=direct 和 go env -w GOSUMDB=off。不要用 GOPROXY=off，它会让 Go 尝试直连源码仓库（如 GitHub），而离线机根本没 git 客户端或 SSH 配置。
-
GOPROXY=direct表示“不走代理，但也不去 git clone，只从本地缓存读”，这是离线唯一安全模式 -
GOSUMDB=off关闭校验；若必须保留校验，可部署内网sum.golang.org镜像并设GOSUMDB=sum.golang.org+https://intranet-sum.example.com - 避免混用：不要一边设
GOPROXY=https://goproxy.cn一边指望离线工作——镜像源本身需要网络
go build -mod=vendor 不能替代完整缓存
go build -mod=vendor 看似能绕过网络，但它只生效于已有 vendor/modules.txt 且内容与 go.mod、vendor/ 目录三者严格一致时。一旦缺失任一模块的源码，或 modules.txt 版本号错位，Go 会 fallback 到 module mode 并报 cannot find module providing package。
更隐蔽的问题是：go mod vendor 不处理 replace 指向本地路径的模块（它只 vendor 替换后的目标），也不包含测试依赖（_test.go 里 import 的包）。所以单纯靠 vendor 目录，在离线 CI 构建中极易失败。
- 真正稳妥的做法是：先在联网机完成
go mod download all，再执行go mod vendor，最后把vendor/和完整的$GOPATH/pkg/mod一起打包 - 若只允许传
vendor/，务必在联网机构建前运行go test -mod=mod -c ./...触发测试依赖解析，再go mod vendor -
go build -mod=vendor时，Go 仍会读取go.sum并校验 vendor 内文件哈希，所以go.sum必须随项目一起带入离线环境
离线构建最易被忽略的点是：模块缓存路径、校验开关、以及 go.sum 文件的完整性三者必须同步。少一个，go build 就可能静默 fallback 到网络模式，或者报错信息完全不提示真实原因。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
