不能用 strings.Split + int 比较，因无法正确处理“1.10.0”>“1.2.0”、预发布标识（如 rc1 < stable）、构建元数据忽略等 SemVer 规则，且会 panic 于 “1.2.3-rc1” 等非纯数字格式；Go 标准库无 SemVer 支持，必须用 blang/semver/v4 等第三方库。
直接用 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 < beta < rc < ""）、构建元数据忽略逻辑、零填充规则都容易漏
如何在微服务启动时加载并校验自身版本
服务启动时读取自己的版本（比如从 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）时，必须靠导入路径隔离 + 版本号显式比对来控制行为分支。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 调用方拿到被调服务返回的
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 < 2，否则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 这种非规范字符串出现时，你的代码是否还能稳住——这些边界情况，比语法解析本身更消耗调试时间。
