唯一可靠解法是启用vendor并提交到git，执行go mod vendor生成vendor/目录，构建时强制使用go build -mod=vendor；replace+私有归档可应对高风险依赖，goproxy缓存不可靠。
模块被作者删库，go build 直接失败，不是网络问题，也不是配置错误——这是真实发生的供应链断裂。唯一可靠解法是提前切断对外部源的 runtime 依赖，把关键模块“钉死”在本地。
go.sum 校验失败 ≠ 依赖丢失，但它是第一个警报
当作者删库后，go mod download 可能仍成功（代理缓存还在），但 go build 或 go run 会突然报 checksum mismatch 或 no matching versions for query "latest"。这不是偶然，而是 go.sum 里记录的哈希值找不到对应源码了。
-
go.sum不是备份，只是校验快照；它不包含代码，只存哈希和路径 - 删库后，即使你本地
pkg/mod缓存里还有 zip 包，Go 也会拒绝加载（校验失败） - 临时绕过校验（
GOSUMDB=off）能跑通一次，但下次go mod tidy会重新拉取并失败
vendor 目录不是可选，而是生产环境的底线
启用 vendor 并提交到 Git，等于把所有依赖的精确版本源码“物理锁定”在项目里。删库、断网、代理失效都不影响构建。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 执行
go mod vendor生成vendor/目录（注意：不是go mod vendor -o vendor，后者无效） - 必须把整个
vendor/提交进 Git —— 否则 CI 构建时go build -mod=vendor会报cannot find module providing package - 构建时强制使用本地依赖：
go build -mod=vendor；CI 脚本里务必显式加上这个参数 - ⚠️ 坑：
vendor不会自动更新，go mod tidy后需再跑一次go mod vendor才能同步
replace + 私有归档，应对高风险依赖
对 GitHub 上小众、无维护者、或已明确标记 deprecated 的模块，不能只靠 vendor —— 它无法解决后续安全补丁或兼容性修复需求。
- 用
replace把原始 import 路径重定向到公司内网 Git（如git.internal.com/forks/xxx） - fork 后定期同步上游（
git subtree pull或手动 cherry-pick），并在go.mod中写死版本号 - 避免写
replace xxx => ./local/xxx—— 这种路径引用在 CI 或他人 clone 后直接失效 - 验证是否生效：
go list -m all | grep xxx输出应显示你 fork 的 URL，而非原始地址
GOPROXY 缓存只是缓冲，不是保险
哪怕用了 https://goproxy.cn 或自建 Athena Go Proxy，也不能假设“缓存永存”。镜像站可能清理冷门模块、遭遇存储故障、或上游要求下架。
- 代理缓存只保存模块的
@v/vX.Y.Z.zip和@v/list元数据，不保证长期可用 -
go env -w GOPROXY="https://goproxy.cn,direct"中的direct在删库后毫无作用——它只会尝试访问原始仓库，而那里已 404 - 真正起效的是
vendor或replace，代理只是加速初始下载的辅助手段
最易被忽略的一点：很多团队把 go.mod 和 go.sum 提交了，却没提交 vendor/，也没在 CI 中加 -mod=vendor。结果线上发布时依赖突然消失，而本地因为 pkg/mod 缓存还在，完全复现不了问题。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
