go模块私有依赖需同时配置goprivate跳过代理与校验、并显式信任私有git服务器的tls证书；前者仅控制模块拉取路径，后者由go独立执行证书验证，二者缺一不可。
Go 模块依赖管理中不存在“全局校验和信任列表”这种集中式白名单机制。所谓“安全信任”，本质是两件事：让 go 工具链跳过代理与校验（GOPRIVATE），以及确保运行时能验证私有模块服务器的 TLS 证书（RootCAs）。二者缺一不可，且作用域完全不同——前者影响 go mod download，后者影响 http.Client 或任何 HTTPS 请求。
为什么 GOPRIVATE 不等于“信任”
GOPRIVATE 只是告诉 Go：“别走 GOPROXY，直接用 Git 协议拉代码”。它不参与证书校验、不加载 CA、不验证服务器身份。即使你设了 GOPRIVATE=git.internal.company/*，如果 Git 仓库用的是自签名 HTTPS 证书，go mod tidy 仍会卡在 x509: certificate signed by unknown authority。
-
GOPRIVATE的作用仅限于模块路径路由和校验跳过，不触碰 TLS 层 - 它必须配合
GONOSUMDB使用，否则go mod download仍会尝试查 sum.golang.org - 通配符只支持前缀匹配（如
git.internal.company/*），不支持正则或模糊匹配 - 多个域名用逗号分隔，中间不能有空格：
go env -w GOPRIVATE=git.internal.company/*,corp.example.com/internal
HTTPS 私有 Git 仓库必须显式信任其 CA
Go 调用 git clone 时复用系统 git 配置，但 HTTPS 协议下的 TLS 校验由 Go 自己执行（不走系统 curl 或浏览器信任库）。所以即使 git 命令能拉，go mod 仍可能失败。
- 若私有 Git 服务用自签名证书或内网 CA 签发，必须把该 CA 的根证书（
rootCA.crt）加入 Go 运行时的RootCAs - 不能靠
GOINSECURE解决——它只跳过 TLS 证书校验，但会破坏 SNI/ALPN，且无法绕过 Git 的 HTTPS 重定向逻辑 - 正确做法是在代码中加载 CA：
roots := x509.NewCertPool()+roots.AppendCertsFromPEM(caBytes)，再注入到http.DefaultTransport（因为go工具链内部使用http.Client） - 更实用的方案是：把
rootCA.crt放进容器镜像的/etc/ssl/certs/（如 Alpine 需apk add ca-certificates并update-ca-certificates），让 Go 自动加载
避免硬编码凭证和泄露风险
私有模块拉取失败，90% 是认证方式没对齐，而不是“没配置信任”。Git 认证不是 Go 的功能，而是复用 Git 凭据系统。
- HTTPS 方式：不要在
go.mod里写https://token@...，应配置git config --global credential.helper store或使用git-credential-netrc - SSH 方式：确保
~/.ssh/id_rsa权限为0600，且已ssh-add；同时在~/.gitconfig中设置：[url "git@git.internal.company:"] insteadOf = https://git.internal.company/ -
GOINSECURE仅用于跳过证书校验，不是认证替代方案；它对 SSH 无效，对 HTTPS 也不推荐——应优先解决 CA 信任问题 - CI/CD 环境中，用环境变量注入 token 时，务必限制 secret scope，避免
go mod graph或go list泄露凭证
真正的“安全”不是加一层白名单，而是让每条链路都可控：模块路径映射准确、GOPRIVATE 范围最小化、CA 根证书明确加载、Git 认证机制稳定复用。任何试图用一个配置项解决全部问题的做法，都会在跨环境部署时暴露断裂点。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
