最可靠的方式是查历史go.mod文件：用git checkout -- go.mod后grep，或git show v1.2.0:go.mod | grep ；若无历史记录，可用go list -m -versions 查可用版本。
直接改 go.mod 里对应模块的版本号，再运行 go mod tidy，就能回滚——但多数失败不是因为命令不会写，而是没确认版本是否存在、没处理间接依赖冲突、或忽略了 go.sum 校验失败。
怎么查上线前用的那个版本号
别翻 Git 提交记录手动猜，也别靠印象记。最可靠的方式是查历史 go.mod 文件本身：
- 如果项目用 Git 管理，直接
git checkout -- go.mod，然后grep require go.mod | grep - 如果上线前打过 tag（比如
v1.2.0），就用git show v1.2.0:go.mod | grep - 若本地没保留历史
go.mod，且模块已引入过，可用go list -m -versions <module-path></module-path>查所有可用版本，再结合 release 页面或 CHANGELOG 判断哪个是上线时实际用的
改 go.mod 时最容易写错的格式
Go 模块系统对版本字符串非常敏感，写错一个字符就会静默 fallback 到别的版本：
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 必须带
v前缀：github.com/sirupsen/logrus v1.8.1✅，github.com/sirupsen/logrus 1.8.1❌（会被忽略） - pre-release 版本要写全：
v1.9.0-beta.1✅，v1.9.0-beta❌（会跳到v1.9.0） - 大小写必须一致：
github.com/Sirupsen/logrus和github.com/sirupsen/logrus被视为两个不同模块 - 私有模块若走内网 proxy，记得临时设
GOPROXY=direct，否则go list -m -versions可能返回空或 fallback 到 latest
go mod tidy 后还是没生效？先检查这三处
执行完命令，go list -m all | grep <module></module> 仍显示旧版，问题通常出在：
- 该模块是
indirect依赖：go get不会自动写入go.mod，需先在代码中显式import，或运行go get -d <module>@vX.Y.Z</module> - 存在
replace干扰：检查go.mod是否有类似replace github.com/sirupsen/logrus => ./local-logrus的行，它会完全绕过版本声明 -
go.sum校验失败：降级后 checksum 不匹配，报verifying ...: checksum mismatch；删掉go.sum中对应模块的两行，再跑一次go mod tidy
回滚后必须验证的两件事
改完不验证，等于没回滚：
- 跑
go build和关键测试（尤其是涉及该依赖的单元测试），API 删除或方法签名变更会在编译或运行时报错 - 检查
go.sum是否更新了对应模块的校验和，确保完整性；如果用了replace或本地路径，go.sum会生成不同 hash，这点容易被忽略
最常被跳过的其实是间接依赖的版本来源——你以为只动了一个模块，结果它被另一个依赖强制拉高了版本。用 go mod graph | grep <module></module> 看谁在“偷偷”指定版本，比盲猜靠谱得多。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
