3. 升级机制概览
在固件升级回滚方案设计中，第一步不是写升级脚本，而是明确“升级包以什么形态、通过什么通道、在什么时机落到设备上”。不同的升级机制决定了升级包体积、传输耗时、Flash 写入量、失败概率以及回滚策略的复杂度。本节把工程中最常见的五类机制放在同一张图上对比：全量升级、增量升级、差分升级、OTA 升级与本地升级。需要特别说明的是，OTA 与本地升级描述的是“传输通道”，而全量、增量、差分描述的是“包内容形态”，二者是正交维度，实际项目往往是“OTA + 差分”或“本地 + 全量”的组合。
一、核心原理：包形态与传输通道正交
理解五类机制的关键，是把“包形态”和“传输通道”拆开看。全量升级把完整固件镜像写入目标分区，逻辑最简单，但包体积等于固件大小；增量升级只打包发生变化的模块或资源，依赖设备端具备模块化分区与版本识别能力；差分升级基于新旧版本的二进制差异生成补丁，设备端用旧镜像加补丁重建新镜像，包体积最小，但对旧版本基线要求严格。OTA 升级强调通过网络远程下发，天然需要断点续传、签名校验与失败重试；本地升级通过 U 盘、串口或调试口写入，常用于产线烧录和现场救援。
一句话记忆：全量、增量、差分决定“包多大”，OTA、本地决定“包怎么来”。回滚方案必须同时回答这两个问题。
二、方法流程：从升级包到设备落盘
无论采用哪种机制，一次完整升级通常包含以下阶段：版本协商、包下载或读取、完整性校验、写入暂存区、切换启动标志、重启验证、失败回滚。差别在于各阶段的实现细节。例如差分升级在“写入暂存区”前多一步补丁合成，OTA 在“包下载”阶段需要处理网络中断，本地升级则把下载替换为介质读取。
升级流程伪代码：
1. 读取当前版本 cur_ver
2. 获取目标版本 pkg_ver 与包类型 type
3. if type == diff:
require baseline == cur_ver
new_img = apply_patch(cur_img, patch)
elif type == delta:
new_img = merge_modules(cur_img, delta_pkg)
else:
new_img = full_image
4. verify(new_img, signature, crc)
5. write_to_staging(new_img)
6. set_boot_flag(staging)
7. reboot_and_confirm()
8. if confirm_fail: rollback_to(previous)三、案例/场景：不同产品线如何选型
以三类典型设备为例。第一类是电池供电的 NB-IoT 水表，网络流量昂贵且设备分散，优先选择“OTA + 差分”，单次升级包可控制在几十 KB，回滚时依赖服务器保留旧版本差分基线。第二类是车载中控，固件体积大、功能安全要求高，常采用“OTA + 全量 + A/B 分区”，升级失败直接切回旧分区，牺牲流量换取确定性。第三类是工业网关，现场无稳定外网，采用“本地 + 全量”通过 U 盘升级，同时保留串口救援通道，回滚由现场工程师手动触发。
| 机制 | 包体积 | 传输依赖 | 回滚难度 | 典型场景 |
|---|---|---|---|---|
| 全量升级 | 最大 | 低 | 低 | 产线烧录、A/B 分区 |
| 增量升级 | 中等 | 中 | 中 | 模块化固件、资源更新 |
| 差分升级 | 最小 | 高（需基线） | 中高 | 流量敏感、批量 OTA |
| OTA 升级 | 取决于包形态 | 网络 | 中 | 远程批量设备 |
| 本地升级 | 取决于包形态 | 物理介质 | 低 | 产线、现场救援 |
四、误区与复盘
常见误区一：认为差分升级一定优于全量。差分包虽小，但设备端需要旧版本精确匹配，一旦设备版本碎片化，补丁命中率下降，反而增加服务器维护成本。
常见误区二：把 OTA 当成一种包格式。OTA 只是通道，真正决定升级行为的是包形态与分区策略。
常见误区三：忽略本地升级的回滚价值。当 OTA 通道不可用或设备变砖时，本地升级往往是最后一道可操作防线。
复盘建议：在方案设计初期就建立“包形态 × 传输通道 × 回滚策略”的三维矩阵，明确每种组合的适用边界。对差分与增量升级，必须同步设计旧版本基线的保留周期与清理策略，否则回滚能力会随版本迭代逐渐失效。
综上，五类升级机制并非互斥，而是可组合的工程选项。全量升级以体积换简单，增量升级以模块化换灵活，差分升级以基线依赖换流量，OTA 以网络换便捷，本地升级以人工换可靠。回滚方案设计者需要根据设备算力、存储、网络条件与运维成本，选择最合适的组合，并为每种组合预设可验证的回滚路径。