根本原因是受限账户下go仍会触发网络请求、校验和验证及代理重定向；必须设goproxy=direct且gosumdb=off才能彻底离线运行，否则即使有缓存也会因连sum.golang.org或校验失败而卡住或报错。
go mod download 为什么在受限账户里经常卡住或失败
根本原因不是权限不够，而是默认行为会触发网络请求、校验和验证、代理重定向三类联网动作——哪怕你本地已有缓存，Go 仍可能去查 sum.golang.org 或尝试连接 GOPROXY 地址。错误现象常见为：fetching github.com/xxx: 403 Forbidden、verifying github.com/xxx@v1.2.3: checksum mismatch，或干脆无响应卡死。
关键点在于：受限账户下，你无法改系统级证书、不能装新 CA、也没法写 /etc/ssl/certs，所以任何 HTTPS 校验或代理转发都容易崩。
- 必须显式关闭校验：
GOSUMDB=off - 必须绕过代理：
GOPROXY=direct - 不能依赖
go mod tidy自动补依赖——它会尝试拉取replace到远程 URL 的模块，而受限账户根本连不上
如何用 go mod download 预下载并离线复用依赖
核心动作只有一条命令，但前置和后置步骤缺一不可。重点不是“下载”，而是让 Go 相信“所有东西都在本地”。
在有网机器上执行（确保当前目录含完整 go.mod 和 go.sum）：
go mod download all
这条命令会把 go list -m all 输出的所有模块（含 indirect）全部拉到 $GOPATH/pkg/mod/cache。注意：all 是关键字，不是通配符；它不处理 replace 到本地路径的模块，也不管 vendor 目录。
在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface
- 下载完立刻验证：
go mod verify—— 若报错，说明go.sum和缓存不一致，得重新go mod tidy再跑一次download all - 打包时只打
$GOPATH/pkg/mod目录，不要带cache/download子目录以外的 junk 文件 - 离线机解压后，必须确保
GOPATH路径与打包机完全一致，否则 Go 找不到缓存
受限账户下运行 go mod download 的实操要点
即使你已复制好缓存，在受限账户里首次运行 go mod download 仍可能失败——因为 Go 默认会读取环境变量、检查代理、尝试更新 go.sum。
安全执行方式是加锁式环境隔离：
GOPROXY=direct GOSUMDB=off CGO_ENABLED=0 go mod download
这组变量组合能堵死所有联网出口：
-
GOPROXY=direct：跳过所有代理，只查本地缓存 -
GOSUMDB=off：不连sum.golang.org，也不校验远程 checksum -
CGO_ENABLED=0：避免因缺失gcc或头文件导致中途退出（虽然download本身不编译，但某些模块的go.mod里含 build constraints，会触发检查）
如果项目用了 //go:embed 或 //go:build，记得加 -tags 参数匹配构建场景，否则部分模块可能被跳过。
最容易被忽略的三个细节
很多人在离线环境下反复失败，问题不在命令本身，而在路径、时间戳和模块替换这三处。
-
go.mod里的replace如果指向https://，go mod download all会直接忽略它——但go build时仍会去抓，结果就是“下载成功，构建失败”。解决办法：删掉这种 replace，或提前把对应仓库 clone 到本地再用replace ./local/path - 离线机的系统时间若比 UTC 慢超过 5 分钟，
go mod download可能拒绝使用本地缓存（校验逻辑含时间窗口），用date看一眼，必要时手动同步 -
$GOPATH/pkg/mod/cache下的文件权限必须是当前用户可读，尤其从 root 账户打包拷贝过来时，常出现permission denied—— 解压后跑一遍chmod -R u+rw $GOPATH/pkg/mod
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
