go list -m all 中识别 unstable 版本需检查：1. 含“-”且不含“.0”的伪版本（如 v0.0.0-20240501-xyz）；2. 以 -alpha/-beta/-rc/-dev 结尾的预发布版；3. v0.x.y（x>0）等不承诺 api 稳定的版本。
go list -m all 里怎么识别 unstable 版本
Go 模块中“不稳定版本”通常指非语义化版本（如 v0.0.0-20230101000000-abcdef123456）或预发布标签（如 v1.2.0-beta.1、v2.0.0-rc.2）。这些版本在 go list -m all 输出中容易被忽略，但恰恰是测试阶段引入、上线后易出问题的高危依赖。
执行以下命令查看全部模块及其版本：
go list -m -f '{{.Path}} {{.Version}}' all
重点关注满足任一条件的行：
-
Version字符串含-且不含.0（如v0.0.0-20240501123456-xyz），这是 commit-hash 形式，说明该模块未打正式 tag -
Version以-alpha、-beta、-rc、-dev结尾（如github.com/some/lib v1.3.0-rc.1） -
Version是v0.x.y且x > 0（如v0.5.0），v0 大版本不承诺 API 稳定性，尤其当它被多个间接依赖拉入时风险放大
为什么 go mod tidy 会悄悄引入 unstable 间接依赖
根本原因是上游直接依赖（比如 github.com/xxx/orm）在其 go.mod 中声明了 require github.com/yyy/utils v0.0.0-20240301000000-123456，而你的项目没显式 require 它——go mod tidy 会按 MVS 规则自动选一个满足所有约束的版本，只要它能通过构建，就照单全收。
常见触发场景：
- 上游库用
replace指向本地调试分支，但提交时忘了删掉go.mod中的replace行，导致其go.sum记录了 unstable hash - 某依赖的最新
main分支打了 pre-release tag，而你运行了go get -u，MVS 优先选“最新”，于是拉入-rc版本 - 私有模块未配置
GOPRIVATE，Go 尝试从 proxy.golang.org 解析失败后 fallback 到 git fetch，结果拉到 HEAD commit 对应的 pseudo-version
如何锁定或排除已知 unstable 间接依赖
不能靠删 // indirect 注释来解决——go mod tidy 下次就会把它加回来。必须显式干预版本选择逻辑：
- 若该包你实际用到了（哪怕只 import 一次），直接
go get github.com/yyy/utils@v1.2.3，它会变成非// indirect的 require 行，MVS 从此以它为准 - 若只是被污染、你完全不用它，用
exclude：在go.mod里加一行exclude github.com/yyy/utils v0.0.0-20240301000000-123456，再跑go mod tidy - 若想彻底禁用某类 unstable 版本（比如所有 pseudo-version），CI 中可加校验脚本：
go list -m all | awk '{if ($2 ~ /-([0-9]{8,}|alpha|beta|rc|dev)$/) print $0}' | grep -q . && exit 1
go.sum 里多个校验和意味着什么
如果 go.sum 中同一模块出现多行不同 hash（例如 github.com/yyy/utils v0.0.0-20240301000000-123456 h1:... 和 github.com/yyy/utils v0.0.0-20240401000000-abcdef h1:...），说明该项目历史上曾引入过多个 unstable 版本——即使当前只用其中一个，也表明该依赖路径存在版本漂移风险。
此时不要手动删 go.sum 行，而应：
- 先确认当前生效的是哪一行：
go list -m github.com/yyy/utils - 查它被谁引入：
go mod graph | grep yyy/utils - 定位源头模块，升级或 replace 它，让整个链收敛到稳定版
真正麻烦的不是看到 unstable 版本，而是它藏在三层间接依赖里，且没有显式 require —— 那意味着你改了代码也不会触发编译报错，直到某天上游删掉一个函数才暴露。
