Go构建时依赖版本由go.mod和go.sum共同锁定，go.build不决定版本；只要两文件不变，构建结果就可重现；go.sum必须提交，go.mod需写死语义化版本，-mod=vendor可物理隔离依赖。
构建时依赖版本由 go.mod 和 go.sum 共同锁定，不是“构建命令”决定的
Go 的依赖版本在 go build 执行前就已确定——它完全取决于当前 go.mod 中声明的版本和 go.sum 中记录的校验和。只要这两个文件没变，go build 就永远拉取并使用同一份代码，哪怕远程仓库里那个 tag 已被 force-push 覆盖（此时会因校验失败而中断构建，而不是静默升级）。
常见错误现象：go build 在 CI 上失败，报 checksum mismatch；本地能跑，别人拉下来编译报错；go.mod 没动但 go.sum 多了几行——本质都是构建前依赖状态不一致，而非构建命令本身有问题。
-
go build不接受任何“锁定版本”的参数，它只读取go.mod和go.sum - 想让构建稳定，核心是确保
go.mod里写死语义化版本（如v1.9.3），而非模糊范围（如^1.9.0） -
go.sum必须提交到 Git，删掉或忽略它会导致所有构建都可能失败 - 如果用了
replace，它只影响当前模块的构建，但go.sum仍校验原始模块的哈希（不是 replace 目标路径的）
go build -mod=vendor 是唯一真正隔离构建依赖的方式
默认情况下，go build 从 $GOPATH/pkg/mod 或代理缓存中拉依赖，仍依赖网络和全局状态。-mod=vendor 强制只读取项目根目录下的 vendor/ 目录，彻底切断外部依赖源，这才是构建时“物理锁定”的做法。
使用前提：你得先执行 go mod vendor，它会把所有依赖（含间接依赖）完整复制进 vendor/，并更新 vendor/modules.txt 记录快照。
立即学习“go语言免费学习笔记（深入）”；
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
-
go mod vendor后必须提交vendor/目录（除非团队明确约定不提交） -
go build -mod=vendor会跳过go.sum校验（因为依赖已本地化），但仍依赖go.mod声明的版本做初始解析 - CI 中建议加检查：
go mod vendor && git status --porcelain vendor/ | grep -q '^??' && echo "vendor not committed!" && exit 1 - 注意：
vendor/不解决 replace 问题——replace 指向的本地路径或 fork 仓库仍需存在且可访问
go get @version 是修改依赖版本的唯一可靠方式
想把某个依赖从 v1.8.0 锁定到 v1.9.3？别手动改 go.mod，用 go get 命令。它会同步更新 go.mod 和 go.sum，并验证新版本是否能通过构建。
常见错误现象：手动编辑 go.mod 版本号后，go build 报 missing go.sum entry；或者 go test 突然失败，发现间接依赖被悄悄升级了——这是因为没触发校验和重写。
- 正确操作：
go get github.com/sirupsen/logrus@v1.9.3（会改go.mod+ 写go.sum） - 只想下载不改
go.mod？加-d：go get -d github.com/sirupsen/logrus@v1.9.3 - 避免用
@latest或@main，它们不生成可重现的伪版本，容易导致不同机器解析出不同 commit - 如果模块没打规范 tag，用 commit hash：
go get github.com/gorilla/mux@3f5e24b6，Go 会自动生成v0.0.0-...-3f5e24b6伪版本并锁定
CI/CD 中最容易被忽略的三个破坏点
很多团队以为提交了 go.mod 和 go.sum 就万事大吉，结果 CI 构建还是不稳定。问题往往出在流程里那些“看起来无害”的命令上。
-
go mod tidy默认会添加缺失依赖、删除未引用依赖，并重写go.sum—— 如果它在构建前自动运行，就可能引入新版本。CI 中应禁用，除非明确要更新依赖 -
go get -u或go get -u ./...会升级所有依赖到 latest，绝对禁止在构建脚本中出现 - 没设
GOPROXY时，Go 可能 fallback 到 VCS（如 git clone），而不同 git 客户端对同一 tag 的 shallow clone 行为不一致，导致校验和不同
真正关键的不是怎么锁，而是谁有权限改、什么时候改、改完是否被验证——go.sum 的每一行哈希，背后都是一个不可绕过的信任链。
