go build不会主动回退版本，但因go.mod声明版本在pkg/mod中缺失或校验失败，会从goproxy重新拉取，可能获取意外版本；可靠冻结须用go mod vendor并提交vendor/、启用-go build -mod=vendor。
go build 为什么还会回退版本？
因为 go build 默认不锁定本地缓存行为，它会检查 go.mod 中声明的版本，但若该版本在 pkg/mod 缓存中缺失或校验失败，就会尝试从 GOPROXY 重新拉取——而代理可能已缓存更旧/更乱的版本，或返回 fallback 到 direct 后拉到意外 commit。这不是 bug，是 Go 模块机制默认“按需补全”的表现。
真正可靠的版本冻结方式只有 vendor
把所有依赖固化进项目目录，彻底切断对远程源和本地模块缓存的依赖：
-
go mod vendor生成vendor/目录，含全部模块源码与 .mod/.sum 文件 - 必须把
vendor/提交进 Git（不是忽略它） - 构建时强制用
go build -mod=vendor，此时 Go 完全不查pkg/mod和 GOPROXY - CI/CD 流水线里加检查：
go mod vendor && git status --porcelain vendor | grep -q '^ ' || exit 1，防止 vendor 落后
replace 不等于冻结，慎用于生产
replace 是开发期绕过网络或测试本地 patch 的手段，但它不解决版本可重现问题：
- 指向本地路径（如
replace example.com/lib => ./fix）时，go list -m all仍显示原始版本号，go.sum不更新，校验链断裂 - 指向 tag（如
replace example.com/lib => example.com/lib v1.2.3）看似安全，但go mod tidy可能把它降级为 indirect，且无法阻止其他模块间接引入更高版 - 上线前必须删掉所有
replace行，否则 CI 构建会因路径不存在失败
go.sum 提交不全 = 冻结失效
go.sum 是校验锁，不是可选文件。漏提、误删、或只提了部分行，都会导致：
- 别人
go build时触发自动下载，拉到不同 checksum 的同版本包（比如作者重打了 v1.2.3 tag） -
go mod verify失败，构建中断 - CI 环境因 GOPROXY 差异拿到不同二进制，行为不一致
每次 go mod tidy 或 go get 后，务必 git add go.sum 并确认无遗漏——尤其注意那些带 // indirect 的行，它们也是校验目标。
