是的，go v0模块无稳定性保证；其版本解析规则硬编码为不承诺api兼容性，v0.x.y可随时引入不兼容变更，且go.sum校验因伪版本不可靠而失效。
Go v0 模块真的没有稳定性保证吗
是的，go mod 明确把 v0.x.y 视为“未发布稳定版”，不承诺 API 兼容性。这不是 Go 团队的模糊表态，而是模块版本解析规则硬编码进 go 命令里的行为：只要主版本号是 0，每次 go get 都可能拉下不兼容变更，连 go build 都不会报错。
为什么 go get github.com/foo/bar@v0.12.3 有时会失效
因为 v0 模块不强制要求打 Git tag，很多作者直接 push 到 main 或 dev 分支，然后用 commit hash 当“伪版本”。你写的 @v0.12.3 实际可能对应一个不存在的 tag，go 会 fallback 到最近的 pseudo-version（比如 v0.12.3-0.20230415112233-abc123def456），而下次 go mod tidy 可能自动升级成另一个 pseudo-version —— 表面没变，实际代码已不同。
- 检查真实版本：运行
go list -m -v github.com/foo/bar，看输出里->后是不是你期望的 commit - 锁定 commit：改用
go get github.com/foo/bar@abc123def456（必须是完整 12 位以上 hash） - 避免
@v0.x.y写法：除非对方明确声明该 tag 存在且被 CI 推送，否则它大概率是人工凑出来的字符串
go.sum 对 v0 模块的校验更松吗
不是更松，是根本没用——go.sum 只记录 module path + version + h1:xxx 校验和，但 v0 模块的 version 字符串本身不可靠。同一个 v0.5.0 在不同机器上可能解析出不同 commit，导致 go.sum 里存的校验和对不上，触发 verified checksums did not match 错误。
- 现象：CI 报错
checksum mismatch for github.com/x/y/v0，但本地go build正常 - 原因：本地缓存了旧 commit，CI 拉了新 commit，但两者都叫
v0.5.0 - 解法：删掉
go.sum里该行，再go mod download重新生成；或直接改用 commit hash 作为 version
想用 v0 库又怕崩，最务实的做法是什么
接受它不稳定，但把不确定性关进笼子。别指望作者守约定，自己控制源头。
立即学习“go语言免费学习笔记（深入）”；
- fork 一份到自己组织下，打上带时间戳的 tag（如
v0.12.3-20240520），再go get这个 fork - 在
go.mod里写replace github.com/orig/repo => github.com/your/repo v0.12.3-20240520 - 如果只是临时试用，加
//go:build ignore注释块隔离代码，别让它混进正式构建流程
真正麻烦的不是 v0 本身，是有人一边写 import "github.com/xxx/v0"，一边在 README 里写“API 可能随时调整”——这种组合，比没文档还危险。
