断网部署Go项目时解压失败的核心原因是模块校验、缓存路径与环境变量未协同：必须确保$GOPATH/pkg/mod完整迁移、GOSUMDB=off生效、GOPROXY=direct配置持久化，且go.sum哈希一致、replace路径正确，三者缺一不可。
断网部署 Go 项目时，go mod download 必然失败，但真正卡住或报错的往往不是“下不到”，而是模块解压阶段出问题——比如 verifying github.com/sirupsen/logrus@v1.9.3: checksum mismatch、cannot find module providing package，甚至 go build 静默退出。核心原因：Go 工具链在构建前会校验、解压、重组模块缓存，而这一过程依赖完整路径结构、哈希一致性、环境变量开关三者协同，缺一不可。
为什么 go mod vendor 后仍解压失败
很多人以为 go mod vendor 生成了 vendor/ 目录就等于“全量离线”，但 Go 在构建时仍会尝试读取 go.sum 并验证每个模块的哈希，再从 $GOPATH/pkg/mod 中解压对应版本（即使你没显式用它）。如果本地缓存缺失、路径错位、或 GOSUMDB=off 没生效，就会在解压前校验阶段中断。
-
vendor/只影响源码引用路径，不替代模块缓存机制；go build -mod=vendor仍会读go.sum并尝试从pkg/mod解压元信息 - 若
go.sum里某行哈希值与实际文件不匹配（例如私有模块被手动改过），解压直接拒绝，不提示具体哪个文件 -
go mod vendor不复制golang.org/x/net这类间接依赖的完整缓存结构，只拷贝源码；而go build内部调用go list -m all时仍需从pkg/mod读取模块描述文件（.info,.zip,.mod）
模块缓存目录必须原样迁移，不能只拷 vendor
离线机上真正需要的是 $GOPATH/pkg/mod 下的完整树形结构，包括 cache/、github.com/xxx/yyy@v1.2.3/、sumdb/ 等子目录。只拷 vendor/ 或只拷 mod/ 下的源码，会导致解压时找不到 .zip 包或 .mod 文件。
- 有网机执行：
go mod download -x golang.org/x/net golang.org/x/sys（显式触发下载并打印路径），确认模块已落盘到$GOPATH/pkg/mod/cache/download/ - 打包命令必须保留层级：
tar -czf gomod-cache.tar.gz -C $GOPATH/pkg mod，不是mod/* - 离线机解压目标必须是
$GOPATH/pkg，且$GOPATH值要和有网机完全一致（如/home/user/go）；否则go build查找缓存时路径拼错，等效于没缓存 - 私有模块（如
git.internal.corp/foo）需额外确保：go mod edit -replace=git.internal.corp/foo=../foo，并把../foo目录带上，否则解压时无法定位替换路径
GOPROXY=direct + GOSUMDB=off 必须写入环境变量，不能仅临时 export
很多用户在终端里 export GOPROXY=direct 后运行 go build 成功，但换成 systemd 服务或 CI 脚本就失败——因为子进程不继承当前 shell 的环境变量，而 Go 工具链在解压前会重新读取环境。
立即学习“go语言免费学习笔记（深入）”；
- 正确做法：写入
/etc/profile.d/golang.sh，内容含export GOPROXY=direct和export GOSUMDB=off，然后执行source /etc/profile.d/golang.sh - 验证是否生效：
go env GOPROXY GOSUMDB输出应为direct和off，不是空或默认值 - 注意：
GOPROXY=off是错误写法，Go 不识别；必须是direct（表示跳过代理，但允许本地缓存命中） - 若项目含
replace，还需加export GOPRIVATE=git.internal.corp，否则 Go 仍会尝试走 proxy 校验
解压失败时最该先看的三个地方
当 go build 卡住或报错，别急着重打包，先快速检查这三个点，80% 的问题在这里：
- 运行
go env GOROOT：输出必须是/usr/local/go（或你解压的实际路径），为空说明GOROOT没导出或路径错 - 运行
ls -l $GOPATH/pkg/mod/cache/download/：应能看到大量github.com和golang.org子目录，空则缓存根本没到位 - 运行
go list -m all 2>&1 | head -5：若报verifying ... checksum mismatch，立刻检查go.sum是否被编辑过，或GOSUMDB=off是否生效
模块解压不是黑盒操作，它严格依赖路径、哈希、开关三者对齐。少设一个环境变量，或多删一个 .mod 文件，都可能导致整个构建链在解压环节静默崩塌。
