go默认不复用系统ca证书库，企业内网tls解密网关使用自签名ca重签https流量，导致go mod download因无法验证证书而失败；根本解法是将企业根证书追加至go信任链或配置gocertificatepath（go 1.21+）。
go mod download 报 x509: certificate signed by unknown authority
这是企业内网典型现象：网关开启 TLS 解密（SSL Inspection），用自签名 CA 重签所有 HTTPS 流量，而 Go 默认不信任该 CA，导致 go mod download 在连接 https://goproxy.cn 或 https://proxy.golang.org 时直接失败。
不是代理地址错了，也不是网络不通——curl -v https://goproxy.cn 能看到证书链里有你公司内部的根 CA，但 Go 不读系统 CA 信任库（除非显式配置）。
- 临时验证：加
GODEBUG=nethttpkeepalives=0并配合-v参数看具体在哪一步失败：go mod download -v - 根本解法是让 Go 加载企业 CA：把网关导出的根证书（通常是
company-root-ca.crt）追加到 Go 的信任链中 - Linux/macOS：执行
cp company-root-ca.crt $(go env GOROOT)/ssl/cert.pem（注意是追加，不是覆盖；可用cat company-root-ca.crt >> $(go env GOROOT)/ssl/cert.pem） - Windows：需手动将证书导入“受信任的根证书颁发机构”，再重启终端——Go 会自动读取 Windows 系统证书存储
GOPROXY 设为 https:// 后仍报 dial tcp: i/o timeout
表面是超时，实则是 TLS 握手卡死：Go 尝试建立 HTTPS 连接，但网关解密中间件未正确响应 ClientHello，或握手超时阈值过短。此时 curl 可能成功（因 curl 默认重试、容忍弱协议），而 Go 的 net/http 客户端更严格。
别急着换代理地址——先确认是不是网关策略限制了 Go 的 User-Agent 或 HTTP/2 流量。
- 用
go mod download -x查看最后一条curl命令，复制出来手动加--verbose --http1.1再跑一次，观察是否从 TLS 协商阶段就卡住 - 强制降级 HTTP/1.1：
go env -w GODEBUG=http2client=0 - 绕过 TLS 验证（仅限调试）：
GIT_SSL_NO_VERIFY=true GOPROXY=https://goproxy.cn go mod download—— 注意这不解决根本问题，且GIT_SSL_NO_VERIFY只影响 git 协议依赖，对 HTTPS 代理无效 - 真正有效的临时方案：
GOPROXY=http://goproxy.cn（HTTP 明文）——前提是网关允许 HTTP 流量且代理支持 HTTP 入口；goproxy.cn 确实提供http://端点，但仅限国内 IP，且不推荐长期使用
go get 安装 gopls/dlv 时 fallback 到 golang.org/x/ 直连失败
即使设了 GOPROXY=https://goproxy.cn,direct，go get 仍可能跳过代理，直连 https://golang.org/x/tools，原因在于 Go 工具链部分命令（尤其 go get 在旧版本）对 golang.org/x/ 路径有硬编码逻辑，不完全遵守 GOPROXY。
Go 1.16+ 已废弃 go get 安装工具，改用 go install，它严格走模块代理。
- 必须用：
GO111MODULE=on go install golang.org/x/tools/gopls@latest - 若仍失败，说明
golang.org/x/tools被网关拦截——此时不能靠替换域名（如改成github.com/golang/tools），因为go install会校验 import path 与模块路径一致性 - 稳妥做法：在有网机器上提前下载好二进制，或用
go mod vendor+ 离线缓存方式分发工具依赖 - 检查
go env GOPRIVATE是否误含golang.org——这会导致 Go 绕过代理直连，应清空：go env -u GOPRIVATE
离线环境启用 GOPROXY=off 后 checksum mismatch
设 GOPROXY=off 仅关闭下载代理，但 GOSUMDB 默认仍是 sum.golang.org，Go 仍会尝试联网校验 go.sum，失败后报 verifying github.com/xxx@v1.2.3: checksum mismatch。
这不是缓存损坏，而是校验流程被中断后 Go 的兜底行为：它会尝试用本地缓存生成新 checksum，但算法不一致导致比对失败。
- 必须同步关闭校验：
go env -w GOSUMDB=off - 验证：
go env GOPROXY GOSUMDB应输出off off - 注意：
GOSUMDB=off后，go mod download不再写入或更新go.sum，所有校验完全依赖你打包的$GOMODCACHE是否原始可信 - 若离线机曾联网运行过
go mod tidy，务必先go clean -modcache清空旧缓存，再解压可信缓存目录，否则残留的不完整模块可能触发校验冲突
企业内网的 TLS 解密网关和 Go 的证书验证机制之间存在隐性耦合，最易被忽略的是：Go 不复用系统 OpenSSL 配置，也不读取 /etc/ssl/certs，它的信任链是封闭的。配代理只是表层，加载 CA 才是关键动作。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
