内网离线安装Go需人工下载校验二进制包、统一解压路径、配置GOPROXY/GOSUMDB内网替代方案、导出环境变量并验证，同时根据项目类型合理设置GO111MODULE与GOPATH，显式禁用CGO并规避网络依赖。
内网离线安装 Go 二进制包的正确流程
不能直接 curl https://go.dev/dl/，必须人工下载、校验、分发。核心是确保 go 可执行文件完整且可信，而非依赖网络安装器。
- 从官网
https://go.dev/dl/手动下载对应系统架构的go1.xx.x.linux-amd64.tar.gz（或.windows-amd64.zip），注意选archive版本而非msi或pkg - 用内网可信机器校验 SHA256：下载页面下方有哈希值，运行
sha256sum go1.xx.x.linux-amd64.tar.gz比对 -
解压到统一路径，例如
/opt/go（Linux）或C:\go（Windows），**不要解压到用户家目录下再软链**，避免权限和路径继承问题 - 通过内网配置管理工具（如 Ansible、SaltStack）或手动推送脚本批量部署，确保所有节点解压路径一致
配置 GOPROXY 和 GOSUMDB 实现模块拉取与校验闭环
内网无法访问 proxy.golang.org 和 sum.golang.org，必须替换为可内控的替代方案，否则 go mod download 会卡住或报错 failed to fetch。
- 推荐使用开源代理服务如
athens部署在内网，设置GOPROXY=http://athens.internal:3000；若无条件，可临时设为GOPROXY=direct，但需提前用go mod vendor锁定依赖 -
GOSUMDB=off最简单，但放弃校验——更稳妥的是部署私有sumdb或设为GOSUMDB=sum.golang.org+https://sum.golang.org并配合内网 DNS 解析重定向（需运维配合） - 务必导出环境变量：Linux 下写入
/etc/profile.d/golang.sh，Windows 下用系统属性或登录脚本，避免仅在当前 shell 临时设置 - 验证是否生效：
go env GOPROXY GOSUMDB，输出应为设定值，不是空或https://proxy.golang.org
GO111MODULE 和 GOPATH 在内网项目中的实际取舍
内网项目往往混用旧式 GOPATH 工程和新式模块工程，GO111MODULE 的开关状态直接影响 go build 行为和依赖查找逻辑，不统一会导致“本地能跑、内网 CI 报错”。
- 强制开启：所有项目统一设
GO111MODULE=on，哪怕没有go.mod文件——此时go build会自动生成，并从GOPROXY拉取依赖，适合新项目 - 遗留项目需兼容：若代码根目录无
go.mod且依赖散落在$GOPATH/src，则设GO111MODULE=auto+ 正确配置GOPATH（如/home/user/go），但注意go mod命令将不可用 -
GOPATH仍需保留：即使启用模块，go install编译的二进制默认仍放$GOPATH/bin，所以必须确保该路径在$PATH中，否则命令找不到
构建时常见失败点与绕过方式
内网构建失败往往不是 Go 本身问题，而是环境链路断在了隐式网络行为上，比如 CGO 调用系统库、测试中硬编码外网地址、vendor 目录缺失等。
立即学习“go语言免费学习笔记（深入）”；
-
CGO_ENABLED=0必须显式设置：避免构建时尝试调用gcc或链接动态库（尤其 Alpine 容器内无 libc），内网多数场景不需要 CGO - 检查
go test是否含外网请求：用-v -run ^Test.*$单独跑疑似用例，或临时加if os.Getenv("CI") != "" { t.Skip("skip network test") } - 若用
go mod vendor，确认vendor/modules.txt已提交，且 CI 构建前执行go mod vendor——否则go build -mod=vendor会因缺少文件失败 - 交叉编译注意：
GOOS=linux GOARCH=arm64 go build不触发网络，但若依赖含 cgo 且未预装对应交叉工具链，仍会失败
内网部署 Go 最容易被忽略的是环境变量的持久化范围和模块校验策略的匹配程度——一个节点上 go env 看着正常，但 Jenkins job 启动的子 shell 可能没加载 profile；GOSUMDB=off 解决了拉取问题，却可能让团队误以为依赖安全可控。
