不能用 strings.split + int 比较，因无法正确处理“1.10.0”>“1.2.0”、预发布标识（如 rc1
直接用
semver.Parse解析字符串版本就行，但必须注意预发布标识、比较逻辑和模块路径隔离这三处最容易出错的地方。为什么不能用 strings.Split + int 比较版本号
设备固件或服务版本写成
"1.2.3"很常见，但硬拆成整数切片比对会挂掉：比如"1.10.0"和"1.2.0"拆成[1,10,0]vs[1,2,0]才能正确判大小；而"1.2.3-rc1"或"1.2.3+build2026"会直接 panic。Go 标准库不提供 SemVer 解析能力，必须依赖第三方包。
- 推荐用
github.com/blang/semver/v4（轻量、无依赖、支持完整 SemVer 2.0）- 避免用
github.com/Masterminds/semver（API 更重，v3 已弃用）- 别自己写解析器——预发布标识排序规则（
alpha ）、构建元数据忽略逻辑、零填充规则都容易漏如何在微服务启动时加载并校验自身版本
服务启动时读取自己的版本（比如从
version文件、编译期 flag 或 git tag），必须立刻做语义化解析并验证格式合法性，否则后续所有路由、健康检查、配置适配都可能因版本误判出错。
- 用
semver.MustParse(os.Getenv("SERVICE_VERSION"))强制失败快抛，别用semver.Parse后忽略 error- 若版本来自 git 描述符（如
v1.2.3-5-gabc123），先用正则提取干净的vX.Y.Z部分，再传给MustParse- 建议在
main()开头就解析并存为全局变量var ServiceVersion semver.Version，避免重复解析微服务间通信时怎么用 SemVer 做 API 兼容性决策
不是所有服务调用都要升级到最新版——尤其跨主版本（
v1→v2）时，必须靠导入路径隔离 + 版本号显式比对来控制行为分支。
- 调用方拿到被调服务返回的
X-Service-Version: v2.1.0header 后，用semver.Version解析，再调v.GTE(semver.MustParse("2.0.0"))判断是否进入 v2 分支逻辑- 不要用
v.Major == 2硬判断——万一对方发的是v2.0.0-rc1，按 SemVer 规则它优先级低于v2.0.0，不应视为稳定 v2- 若需降级 fallback，用
v.LT(semver.MustParse("2.0.0"))而非v.Major ，否则 <code>v1.999.999会被误判为“旧版”go.mod 里 require 的版本和运行时版本解析是两回事
go.mod中的require github.com/example/lib v1.5.0是模块依赖约束，它影响编译期代码可见性；而服务自身的v1.5.0是运行时标识，用于灰度、路由、降级策略。两者语义不同，不能混用。
- 别把
runtime.Version()（返回"go1.21.5"）当成服务版本——这是 Go 编译器版本，不是你的服务- 别从
go.mod动态读取当前模块版本（go list -m调用开销大、不可靠），应在构建时注入（如-ldflags "-X main.version=$(git describe --tags)"）- 如果服务同时作为 SDK 被其他项目依赖，它的
go.mod版本必须带/v2路径后缀，而运行时版本字符串仍可用v2.0.0——这是两个独立维度真正麻烦的不是解析，而是版本号出现在哪、谁负责生成、谁负责消费、以及当
v1.2.3+dirty这种非规范字符串出现时，你的代码是否还能稳住——这些边界情况，比语法解析本身更消耗调试时间。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
