固件版本应存为可比较结构而非字符串，推荐用semver.Version解析；设备端需绑定签名防篡改；服务端应拆分为整数字段建索引；回滚依赖A/B分区与版本历史链。
固件版本号怎么存才方便比较
直接用字符串存 "1.2.3" 看似简单，但无法直接用 < 或 > 比较大小——Go 里字符串比较是字典序，"10.0.0" 会小于 "2.0.0"。必须转成可比结构。
推荐用 semver.Version（来自 github.com/blang/semver/v4）或自定义结构体解析。前者支持完整语义化版本规范（含预发布、构建元数据），后者轻量但需自己处理边界。
- 用
semver.Parse("1.2.3-beta+build.1")解析后，可直接用v1.GT(v2)、v1.LTE(v2)等方法比较 - 若只支持
X.Y.Z格式，可用strings.Split()转为整数切片，再逐段比对（注意补零） - 避免用
float64拼接（如1.2.3 → 1002003），易溢出且不兼容带字母的版本（如"1.2.3-rc1"）
设备端如何安全读取和验证固件版本字段
固件版本通常嵌在二进制头部、特定 Flash 区域，或编译时注入到全局变量。关键不是“怎么读”，而是“怎么防篡改”。
如果只是从某个全局变量（如 var FirmwareVersion = "1.5.0"）读取，攻击者可 patch 二进制直接修改该字符串——这在 OTA 升级校验中是致命缺陷。
立即学习“go语言免费学习笔记（深入）”；
- 版本信息应与固件签名绑定：升级包解压后，先用公钥验签，再从已验证的镜像中提取版本字段
- 若需运行时快速获取，建议将版本哈希（如 SHA256(version_string + build_time)）固化在签名段末尾，启动时重新计算并比对
- 避免把版本号存在易擦写的 NVS / EEPROM 区域（除非有写保护+CRC 校验）
服务端如何高效查询某设备当前固件版本并匹配升级策略
常见错误是每次查设备都查数据库全量字段，或者把版本号当普通字符串模糊匹配。
实际要支撑千台设备并发升级调度，得让版本成为可索引、可范围查询的字段。
- 数据库表中单独建
firmware_version_major、firmware_version_minor、firmware_version_patch整数列，并加复合索引；或存semver.Version的Major.Minor.Patch为整数（如100020003），便于BETWEEN查询 - 升级策略配置用 JSON 存储时，避免写
"min_version": "1.2.0"字符串，而应预解析为整数或semver.Version对象缓存，否则每次匹配都要重复解析 - 设备上报版本时，服务端应校验格式合法性（比如拒绝
"v1.2"或空字符串），防止脏数据污染策略引擎
升级失败后如何回滚并保留旧版本元数据
很多实现只保存“当前版本”，导致回滚时不知道上一版是什么、有没有对应镜像、签名是否有效。
真正可靠的回滚，依赖两个东西：一是本地多版本镜像快照，二是版本元数据链式记录。
- 设备 Flash 划分至少两块固件区（A/B），每次升级写入空闲区，成功后再更新启动标志位；失败则保持原区启动
- 每次成功启动后，将本次版本号、时间戳、镜像 CRC 写入独立的
version_history日志区（非易失存储），最多保留 3~5 条 - 服务端下发升级包前，应检查设备历史版本链中是否存在可回退目标（例如当前是
1.5.0，但历史里只有1.3.0，中间1.4.0失败未记录，则不能盲目回退到1.4.0）
版本管理最常被忽略的点不是解析逻辑，而是“谁在什么时候、基于什么依据认定这个版本可信”。一次没校验签名的版本读取，可能让整个升级信任链失效。
