写v1.2.3是精确锁定该版本，写v1.2则取v1.2.x中最高patch版本（如v1.2.7）并写入go.mod；二者最终commit可能完全不同，且go.mod中始终记录具体版本号而非范围表达式。
go get 时写 v1.2.3 和 v1.2 有什么区别
写 v1.2.3 是精确锁定，写 v1.2 是“取 v1.2.x 中最新可用版本”，二者最终落地的 commit 可能完全不同。
Go 不支持 npm 风格的 ^ 或 ~ 语法，所谓“模糊”只是省略部分字段后的语义推导：
-
go get example.com/pkg@v1.2.3→ go.mod 中记录v1.2.3，后续go mod tidy不会主动升级 -
go get example.com/pkg@v1.2→ 工具链查所有v1.2.xtag，选最高 patch（如v1.2.7），并写入 go.mod -
go get example.com/pkg@v1→ 同理，取当前主版本下最高 minor.patch（如v1.9.1）
注意：这些“模糊写法”只在 go get 命令中有效，执行后 go.mod 里始终存的是具体版本号（如 v1.2.7），不是范围表达式。
为什么 go list -m -versions 显示的版本里没有 main 分支
go list -m -versions 只读取 Git 仓库中符合 v\d+\.\d+\.\d+（或带预发布后缀）格式的 tag，不识别分支名、commit hash 或 lightweight tag。
常见误解是以为 go get -u 能拉到最新代码 —— 实际它只会升到满足当前主版本约束的**最新合法 tag**。比如你 require v1.2.0，远程有 v1.2.1 和 v1.3.0，go get -u 就会选 v1.3.0；但即使 main 分支已合并大量新功能，只要没打 v1.3.1 这样的 tag，就不会被列出或拉取。
若真要试未打 tag 的代码，只能用：go get example.com/pkg@commit-hash 或 @main，但这会产生伪版本（如 v0.0.0-20260803120000-abc123def456），且 go list -m -versions 不会显示它。
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
go.mod 中 require 行写 v1.2.0，但实际构建用了 v1.2.3，为什么
这是最小版本选择（MVS）算法的正常行为：Go 不强制使用 require 行声明的版本，而是收集所有依赖的版本约束，选出满足全部条件的最低兼容版本 —— 注意，“最低”指语义化版本数值最小，不是“最早发布”。
例如：
- A 依赖
github.com/x/y v1.2.0 - B 依赖
github.com/x/y v1.2.3 - MVS 会选择
v1.2.3（因v1.2.0不满足 B 的约束）
如果你发现实际加载版本高于 require 行所写，说明有其他依赖项提出了更高要求；用 go mod graph | grep x/y 可定位是谁拉的高版本。想强制锁定，就得把 require 行显式改为 v1.2.3，再跑 go mod tidy。
伪版本（pseudo-version）到底锁定了什么
伪版本形如 v0.0.0-20260803120000-abc123def456，它锁定的是一个确定的 commit，比 tag 更精确，也更稳定。
其中：
-
20260803120000是该 commit 的 author date（年月日时分秒） -
abc123def456是 commit hash 的缩写 - 只要这个 commit 在远程仓库中没被 force-push 覆盖，该伪版本就始终可重现
它常出现在三种场景：模块没打合规 tag、你手动指定 @commit-hash、或上游 tag 命名不规范（如缺 v 前缀）。这种写法本质是“跳过 SemVer，直锁 commit”，适合调试和临时修复，但不应长期用于生产环境 —— 因为缺乏语义承诺，别人无法判断它是 PATCH 还是 BREAKING CHANGE。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
