内网离线安装Go二进制包必须人工下载校验、统一解压路径、配置GOPROXY/GOSUMDB内网替代方案、导出环境变量并验证，同时根据项目类型合理设置GO111MODULE与GOPATH，显式禁用CGO并规避网络依赖。
内网离线安装 Go 二进制包必须人工校验，不能依赖 curl 或自动化脚本
企业内网无法访问 https://go.dev/dl/，直接运行 curl 下载会失败或返回 403/超时。核心动作是：在有外网的可信机器上，从官网或国内镜像站（如清华、阿里云）手动下载 go1.22.5.linux-amd64.tar.gz 这类 archive 包，而非 MSI 或 pkg；用页面下方公布的 SHA256 值比对本地文件哈希：sha256sum go1.22.5.linux-amd64.tar.gz；解压路径统一设为 /opt/go（Linux）或 C:\go（Windows），**禁止解压到用户家目录再软链**——否则 Ansible 推送后权限错乱、go env GOROOT 指向不稳定。
GOPROXY 和 GOSUMDB 必须显式覆盖，否则 go mod download 会卡死
默认值 GOPROXY=https://proxy.golang.org,direct 和 GOSUMDB=sum.golang.org 在内网完全不可达，执行 go build 或 go mod tidy 时进程挂起，日志只显示 “fetching” 无报错。正确做法：
- 有私有代理（如 Athens）：设
GOPROXY=http://athens.internal:3000，并确保该地址 DNS 可解析、端口可达 - 无代理但已
go mod vendor锁定依赖：设GOPROXY=direct，同时GOSUMDB=off（放弃校验）或GOSUMDB=sum.golang.org+https://sum.golang.org+ 内网 DNS 劫持（需运维配合） - 环境变量必须写入全局配置：Linux 用
/etc/profile.d/golang.sh，Windows 用系统级环境变量，避免仅在 CI 脚本里export
GO111MODULE 开关决定构建行为，混用会导致 CI 失败
同一套代码在开发者本地能跑，CI 上报 cannot find module providing package，大概率是 GO111MODULE 状态不一致。关键判断点：
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 新项目（含
go.mod）：强制设GO111MODULE=on，即使没go.mod也会自动生成，依赖走GOPROXY - 老项目（无
go.mod，依赖全在$GOPATH/src）：设GO111MODULE=auto，且必须配好GOPATH（如/home/app/go），否则go get找不到位置 -
go install输出的二进制默认放$GOPATH/bin，该路径必须在$PATH中，否则command not found
CGO_ENABLED=0 是离线编译安全底线
默认开启 CGO 会导致构建时调用系统 C 编译器（gcc）、链接 libc，内网若未装 build-essential 或对应 devtoolset，go build 直接报 exec: "gcc": executable file not found in $PATH。解决方式只有两个：
立即学习“go语言免费学习笔记（深入）”；
- 所有构建命令显式加前缀：
CGO_ENABLED=0 go build -o app - CI 脚本开头统一设环境变量：
export CGO_ENABLED=0，避免遗漏
注意：启用 CGO 后生成的二进制不是纯静态链接，部署时需确认目标机系统库版本兼容——这点常被忽略，直到上线后 core dump。
