私有依赖安全策略必须与go mod行为、校验机制、CI流程深度耦合；Go默认跳过私有模块GOSUMDB校验，需显式配置GOSUMDB=sum.golang.org并配合replace+require锁定哈希，私有模块路径须用完整域名声明，go.sum中必须包含其module path的checksum条目。
直接说结论：私有依赖安全策略不是“配个 GOPROXY 就完事”，它必须和 go mod 行为、校验机制、CI 流程深度耦合；否则你只是把公开漏洞换成了内部仓库里的未知风险。
go mod 如何真正信任私有模块？
Go 默认不验证私有模块来源，go get 会跳过 GOSUMDB 校验，这是最大盲区。关键不是“能不能拉下来”，而是“拉下来的包有没有被篡改”。
- 必须显式关闭默认跳过行为：在 CI 或构建机上设置
GOSUMDB=off是危险操作，应改为GOSUMDB=sum.golang.org并配合replace+require锁定哈希 - 私有模块路径需在
go.mod中声明完整域名（如git.example.com/internal/utils），不能用./internal这类相对路径——否则go mod verify无法定位其 checksum - 若使用自建 proxy（如 Athens），必须启用
verify模式，并确保其后端存储保留原始.mod和.zip的 SHA256 校验值，而非仅缓存文件
私有仓库认证与凭证管理陷阱
常见错误是把 token 写进 .netrc 或环境变量里提交到代码库，或让 go get 交互式输密码——这在 CI 中必然失败。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- Linux/macOS 下，用
git config --global credential.helper store配合~/.git-credentials（权限必须600），Go 会复用 git 凭据 - Windows 上优先用 Windows Credential Manager，避免明文存储；不要依赖
git config --global credential.helper cache（超时后 CI 构建会卡住） - CI 环境中，用平台原生 secret 注入（如 GitHub Actions 的
secrets.PRIVATE_REPO_TOKEN），并通过git config动态写入凭证，而不是拼接 URL：https://$TOKEN@github.com/org/private-repo
go build 时如何强制隔离私有依赖？
go build 默认会尝试解析所有 require，包括私有模块，但若网络不通或凭证失效，它不会报错，而是静默降级为本地缓存——这导致构建产物不可重现。
立即学习“go语言免费学习笔记（深入）”；
- 构建前必须运行
go mod download，并检查退出码；若失败，CI 应立即中断，不能靠go build自动 fallback - 用
go build -mod=readonly阻止任何自动修改go.mod或go.sum的行为，避免意外引入新版本 - 对私有模块做
replace时，目标路径必须是绝对路径或完整 Git URL（如replace git.example.com/internal/utils => https://git.example.com/internal/utils v1.2.0），相对路径=> ./local-utils在跨机器构建时会失效
最易被忽略的点：私有模块的 go.sum 条目是否包含其完整 module path 的 checksum。如果只看到 github.com/... 而没有你的 git.example.com/... 条目，说明 Go 根本没把它当真实依赖校验——这时你所谓的“私有策略”只是幻觉。
