go mod tidy 不会回退依赖版本，而是将依赖解析为当前可用的最新兼容版本；若需回退，应手动修改 go.mod 或用 go get @version 锁定旧版，并处理 go.sum 校验失败问题。
go mod tidy 会自动升级依赖，不是回退工具
go mod tidy 的作用是同步 go.mod 与实际代码中 import 的依赖关系：添加缺失的模块、移除未使用的模块，并**将每个依赖解析为当前可用的最新兼容版本**（通常是最新的 minor 或 patch 版本）。它不会回退，也不会保留历史版本偏好。
如果你刚执行了 go mod tidy，发现某个依赖被意外升到了 v1.12.0，而你需要 v1.11.3，那不是 go mod tidy 的问题——是你没锁住版本，或者本地缓存/代理返回了新版本。
- 它不读取
go.sum来决定用哪个版本 - 它不关心你之前
go get过什么，只看当前 import 和go.mod约束 - 如果
go.mod里写的是github.com/some/pkg v1.11.3，go mod tidy会坚持这个版本
（只要能 resolve）
（只要能 resolve）手动指定并锁定旧版本的正确姿势
回退本质就是「告诉 Go 使用某个已知可用的旧版」，核心操作是修改 go.mod 并确保该版本可下载。常见方式有：
- 直接编辑
go.mod，把对应模块行改成目标版本，例如：require github.com/gorilla/mux v1.8.0
- 用
go get显式拉取旧版：go get github.com/gorilla/mux@v1.8.0
，然后运行go mod tidy整理（此时 tidy 不会覆盖你刚 get 的版本） - 如果模块已打 tag，但本地无法 resolve（比如私有仓库或网络限制），需确认
GO_PROXY设置是否绕过了认证，或临时设为direct：export GO_PROXY=direct
注意：go get xxx@commit-hash 也合法，但 commit 版本不会出现在官方 proxy 缓存中，CI 环境容易失败，生产环境慎用。
回退后 go.sum 校验失败怎么办
常见错误信息：
verifying github.com/some/pkg@v1.8.0: checksum mismatch。这说明你本地
go.sum 记录的哈希值，和当前下载内容不一致——可能因为：模块作者重写了 tag、你用了镜像源但镜像不同步、或本地文件被篡改。
- 先运行
go clean -modcache清掉本地 module cache，再重新go mod download - 如果仍失败，且确认该 tag 是可信的（比如查过 GitHub release 页面），可强制更新校验和：
go mod download -dirty
（仅调试用）或更安全的做法：go mod verify && go mod sum
查看差异，再手动修正go.sum中对应行（不推荐） - 长期方案：在 CI 中固定
GO_CHECKSUMDATABASE=off是危险的，应优先排查网络代理或私有 registry 的一致性
批量回退多个模块？别用脚本硬改 go.mod
有人写 shell 脚本批量替换 go.mod 里的版本号，这很危险：Go 模块语义化版本有兼容规则（如 v1.x.y → v1.x+1.y 可能不兼容），且 replace、exclude、多模块 workspace（go.work）会让正则失效。
真正稳健的做法是：
- 用
go list -m -u all查出所有可升级项，人工比对 changelog 决定是否回退 - 对必须锁定的模块，统一用
go get xxx@vX.Y.Z逐个声明，再go mod tidy - 若项目已用
go.work，回退需在 workspace 级别操作，go mod tidy必须在go.work所在目录执行
最易被忽略的一点：go.mod 里写的版本，只是“最低要求”。如果另一个依赖间接引入了更高版，Go 会自动提升——这时得用 replace 强制降级，但要同步验证所有 transitive 依赖是否仍能编译通过。
