真正可靠的依赖保护靠亲手存下的副本，而非假设版本永存；必须通过vendor目录提交、私有代理缓存或内部fork实现离线可用，否则公开tag可能随时404。
模块发布后版本丢失不是偶然事故，而是缺乏归档意识的必然结果；只要没做本地备份或代理缓存，任何公开 tag 都可能在某天 404。
go.sum 提交不等于依赖安全
很多人以为把 go.mod 和 go.sum 提交到 Git 就万事大吉，其实这只是校验入口，不是内容备份。一旦原始仓库删除 tag 或域名失效，go mod download 就会失败——go.sum 里只有哈希，没有源码。
-
go.sum不可手动编辑，校验失败时 Go 会直接报checksum mismatch错误，而非尝试 fallback - 公共代理（如
proxy.golang.org）不保证长期存档，某些小众模块可能只缓存数月 - Bitbucket、GitLab 自托管仓库若未配置 archive 策略，删 branch/tag 后无法恢复
vendor 目录必须提交且构建强制启用
真正能离线构建的只有 vendor/ 目录，但它默认不参与构建，必须显式启用。
- 执行
go mod vendor生成目录后，需 完整提交所有文件（包括vendor/modules.txt），不能 .gitignore - CI/CD 中构建命令必须加
-mod=vendor：例如go build -mod=vendor ./cmd/app - 本地开发也建议统一用该 flag，避免因 GOPROXY 差异导致“我本地能跑，CI 报错”
- 注意：
vendor不解决 replace 指向本地路径的问题——那些路径不会被复制进去，需单独处理
私有代理是防丢底牌，不是可选优化
靠公共代理扛风险等于把钥匙交给别人保管。企业级项目必须部署可控的代理缓存。
- 推荐方案：JFrog Artifactory 或 Athenas Proxy，它们会自动缓存所有拉取过的 module 版本，包括 commit hash 和 tag
- 环境变量设置要带 fallback：例如
GOPROXY=https://artifactory.internal/proxy,https://goproxy.cn,direct - 关键点：
direct必须放在最后，否则一旦代理挂掉，Go 会跳过它直连原始源，重蹈 404 覆辙 - 定期巡检代理日志，确认关键模块（如
golang.org/x/...、内部 SDK）是否已缓存成功
replace + fork 是高危操作，但有时不得不做
当上游模块已删库、tag 被撤回、或作者拒绝修复 bug 时，replace 是最后一道防线，但极易埋雷。
- 必须同步改 import 路径：如果原模块是
github.com/old/pkg，而你 fork 到git.internal.com/forks/pkg，代码里所有import "github.com/old/pkg"都得改成新路径 -
replace行写进go.mod后，务必运行go mod tidy，否则go list -m all不会显示 => 映射关系 - 上线前必须 grep 检查：
grep -r "replace.*old/pkg" .，残留的 replace 会导致不同环境行为不一致 - 更稳妥的做法是：fork 后打新 tag（如
v1.2.3-internal.1），并在go.mod中 require 这个新 tag，而非用 replace 指向 master 分支
真正可靠的依赖保护，从来不是靠“它应该还在”，而是靠你亲手存下的那一份副本——无论是 vendor 目录里的文件、代理里的缓存，还是内部 Git 上的 fork。版本丢了不可怕，可怕的是你从没想过它会丢。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
