Go默认忽略预发布版本，除非显式指定；MVS算法将其视为比对应正式版更旧，故@latest不会选中，go mod tidy也不主动引入，仅当require中写死如v1.2.3-beta.1时才生效。
Go 默认忽略预发布版本，除非你显式指定；它不参与版本选择，也不被 @latest 选中。
预发布版本在 go.mod 中的实际行为
Go 的模块解析器（MVS 算法）将带预发布标识的版本（如 v1.2.3-beta.1、v2.0.0-rc.2）视为“比对应正式版更旧”，因此它们不会被自动升级或默认选用。即使 v1.2.3-beta.1 在时间上晚于 v1.2.2，Go 仍认为 v1.2.2 “更新”。
常见表现：
- 执行
go get example.com/pkg@latest不会拉取v1.2.3-beta.1，而是停在v1.2.2 -
go list -m -versions example.com/pkg会列出预发布版本，但go mod tidy不会主动引入它们 - 若
go.mod中已写死require example.com/pkg v1.2.3-beta.1，则能正常解析和构建，但会被标记为“不稳定依赖”
何时必须显式写死预发布版本
仅当你要验证尚未发布的功能、配合上游模块的临时发布流程，或调试一个已知存在于 beta/RC 中的修复时，才需要手动指定。这时不能依赖语义化版本的隐式规则。
立即学习“go语言免费学习笔记（深入）”；
操作要点：
- 直接编辑
go.mod，写入完整带标签的版本，例如：require example.com/pkg v1.5.0-rc.1 - 避免混用：不要在同一个
require块中对同一模块既写v1.5.0-rc.1又写v1.5.0，go mod 会报错 - 注意主版本路径：如果预发布版属于
v2主版本，模块路径必须含/v2，例如example.com/pkg/v2，否则解析失败
预发布版本与 replace/exclude 的配合风险
replace 和 exclude 对预发布版本的支持有限且易出错。
典型陷阱：
-
exclude example.com/pkg v1.5.0-rc.1无法阻止v1.5.0-rc.2被选中——exclude是精确匹配，不支持通配或范围 -
replace example.com/pkg => ./local-pkg后，本地模块若未打 tag 或无go.mod，go 会生成伪版本（如v0.0.0-20260720143211-abc123def456），这不属于预发布，但行为类似：不可预测、不被@latest覆盖 - CI 环境中若缓存了旧的
go.sum条目，而你切换到预发布版本，可能触发校验失败，需手动go mod download并确认
预发布版本不是“测试版开关”，它是语义化版本的一部分，但 Go 工具链对其做了明确降权处理。真正容易被忽略的是：当你在 go.mod 里写了 v1.0.0-beta，整个团队都得意识到——这个依赖不会随 go get -u 自动更新，也不会被其他模块的 require 隐式拉入；它是一条需要人工盯住的线。
