Go模块不支持版本范围语法，仅接受精确版本如v1.9.0；go get默认同主版本内升级，exclude屏蔽问题版本，replace临时替换依赖，主版本升级需路径变更。
Go 模块（go.mod）不支持类似 npm 的波浪号（~）或插入号（^）语义化版本范围，所有依赖必须声明为**精确版本**或使用 go get 自动解析后的确定性版本；所谓“版本范围”只能靠人工约束 + replace/exclude 辅助控制。
go.mod 中无法写 github.com/sirupsen/logrus v1.9.x 这类模糊版本
Go 工具链会直接报错：invalid version: unknown revision v1.9.x。模块版本字段只接受以下格式：
-
v1.9.0、v2.0.0+incompatible等完整语义化标签 -
master、main、HEAD（不推荐，非可重现构建） -
commit hash（如7f2e87a，仅用于临时调试）
没有通配符、区间、或“最新补丁版”语法。这是 Go 设计上对可重现构建的强制要求。
用 go get 控制主版本升级边界
真正影响版本选择的是 go get 命令的隐式规则：它默认只升级到**同一主版本下的最新次版本/补丁版本**，不会跨 v1 → v2 主版本（除非显式指定）。例如：
立即学习“go语言免费学习笔记（深入）”；
go get github.com/sirupsen/logrus@latest
若当前是 v1.8.1，且仓库有 v1.9.3 和 v2.1.0，则只会升到 v1.9.3 —— 因为 v2.1.0 属于不同模块路径（需 github.com/sirupsen/logrus/v2）。
- 想锁死补丁级更新？用
go get github.com/sirupsen/logrus@v1.9.0 - 想允许次版本升级但禁止主版本跃迁？不加
@直接go get github.com/sirupsen/logrus即可 - 检查实际生效版本：运行
go list -m all | grep logrus
用 exclude 和 replace 实现逻辑上的“版本限制”
当某依赖的某个版本存在严重 bug，又不能立刻升级到下一主版本时，可用 exclude 显式屏蔽问题版本：
exclude github.com/gorilla/mux v1.8.0
这样即使其他依赖间接引入 v1.8.0，go build 也会失败并提示冲突，迫使你处理。
replace 则用于临时替换（如本地调试、fork 修复）：
replace github.com/gorilla/mux => ../mux-fix
-
exclude不改变依赖图结构，只做校验拦截 -
replace会修改实际加载的代码路径，且仅对当前模块生效（不传递给下游） - 二者都写在
go.mod里，提交前需确认是否属于长期策略
真正的版本管理难点不在语法表达，而在理解 Go 模块的“主版本即新模块”原则——v1 和 v2 是两个完全独立的导入路径，不是可选范围。忽略这点，硬凑“范围”只会让 go.sum 失控、构建失败频发。
