应禁用默认代理设goproxy=direct或部署内网离线代理（如athens/goproxy.cn），并同步配置gosumdb=off或指向内网校验服务，否则go build仍会因sum.golang.org不可达而失败。
go mod download 在内网报 connection refused 怎么办
这不是 Go 安装失败，而是模块代理不可达——Go 1.13+ 默认走 proxy.golang.org，内网直连必然超时或拒绝连接。
- 临时应急：运行
go env -w GOPROXY=direct，让 Go 直接从源码仓库拉取；但仅适用于已预置vendor/或内网有私有 Git（如 Gitee、GitLab）且地址已写死在go.mod中的场景 - 真正可用的方案是部署离线代理服务：用
athens或goproxy.cn的离线镜像版，在内网某台能出网的机器上跑goproxy（Go 实现），再通过内网 IP 暴露端口（如http://192.168.1.100:8080），然后设go env -w GOPROXY=http://192.168.1.100:8080 - 必须同步处理校验和：否则
go build仍会尝试访问sum.golang.org。要么关掉校验go env -w GOSUMDB=off，要么部署内网sum.golang.org镜像并指向它
离线环境如何确保 go mod download 全量拉取成功
断网时 go mod download 和 go get 会直接失败，唯一可行路径是在有网机器上提前拉取完整依赖树并打包带走。
- 确保目标项目
go.mod和go.sum已提交且稳定，不要含未提交的本地修改 - 在联网机器执行
go mod download -json查看将拉取哪些模块及其版本（便于核对完整性） - 运行
go mod download，它会把所有依赖写入$GOPATH/pkg/mod/cache目录；注意用与目标环境完全一致的 Go 版本（如go1.21.6）执行下载，否则go.mod中的// indirect标记和校验和可能不兼容 - 打包整个
pkg/mod/cache目录（注意保留目录结构），拷贝到离线机器对应位置；离线机需设置GOPROXY=direct，否则 Go 仍会尝试连接代理地址
go mod vendor 后为什么编译还失败
go mod vendor 把依赖复制进 vendor/，但它不处理 replace 的本地模块，也不自动包含 // indirect 的间接依赖——这些都得靠 go mod tidy 先理清。
- 执行顺序必须是：
go mod tidy→go mod vendor→ 检查vendor/modules.txt是否覆盖全部go.sum条目 - 若依赖中含 cgo 或汇编文件（如
net包调用系统 DNS），vendor后仍需目标机器安装对应 C 工具链（gcc、pkg-config） - 私有模块托管在 GitLab/GitHub Enterprise 时，确认其域名已加入
GOINSECURE（如export GOINSECURE="git.internal.company"），否则 TLS 验证失败也会表现为 checksum error
交叉编译产物在目标机器报 not a valid ELF executable
本质是 GOOS/GOARCH 设定与目标系统不匹配，或 CGO 混入了宿主机动态链接依赖。
- 禁用 CGO 是最稳妥的做法：
CGO_ENABLED=0 go build -o myapp-linux-amd64。一旦启用 CGO，编译产物就依赖目标机器上的 libc 版本，而内网服务器往往系统老旧 - 确认目标平台真实架构：Linux 下用
uname -m看是x86_64还是aarch64；Windows 下注意区分amd64和arm64；不要凭经验硬猜 - 交叉编译前清空缓存：
go clean -cache -modcache，避免旧构建残留影响新产物；尤其是从 macOS 编译 Linux 二进制时，$HOME/Library/Caches/go-build里可能混入 darwin
go mod download 到 go build 全程无任何域名解析、TCP 连接尝试——这点最容易被忽略，也最难验证。
