定义
Rollback（回滚）指 OTA 升级失败或异常时，自动或手动恢复到上一版本固件。A/B Partition 架构可支持快速回滚，无需重新下载旧版本。
触发方式
回滚可分为：自动回滚—设备升级后自检失败（如启动超时、关键服务异常）时自动切回旧分区；手动回滚—运维人员在平台侧对单台或批量设备发起回滚指令；灰度回滚—Gray Release 灰度期间发现异常，暂停推送并对已升级设备执行回滚。
A/B 分区与回滚效率
采用 A/B Partition 时，旧版本固件仍保留在另一分区，回滚仅需更新启动标志并重启，耗时通常在秒级，无需重新下载。单分区架构下，回滚需重新下载旧版本固件，耗时长且依赖网络，适合作为兜底方案。
回滚策略配置
平台可配置回滚策略：升级失败重试次数、自检超时时间、是否允许自动回滚等。建议在 FOTA 任务中设置合理的观察期，结合设备上报的版本与状态，及时识别异常并触发回滚，降低批量变砖风险。
回滚恢复的是启动槽位还是包体
回滚的技术含义取决于设备怎样保存旧版本。双分区设备的旧系统仍在另一个槽里，回滚只改下一次启动用哪一个槽，再重启，不需要重新下载。单分区设备没有留下可启动的旧系统，回滚必须先把旧包再次传到设备上，写完并校验后才能重启。平台若对两种设备下发同一种“立即切回”指令，单分区设备会因找不到旧槽而停在失败状态，任务看起来却像已经发出。
因此任务在创建时就要读到设备上报的分区能力和当前槽位，而不是按产品手册假定全部支持双分区。旧包必须仍可获取：被仓库清理掉的版本无法作为回滚目标。回滚目标应是“上一份已知可运行的版本”，不一定是版本号数字上的前一个；中间若有撤回的构建，不能按号回退到那一版。切换是否成功，以设备再次上线后报告的运行版本为准，而不是以重启命令已送达为准。
观察期结束前不宜宣告成功
升级写入完成只说明新槽可启动，不说明业务进程已经稳定。观察期内设备应上报关键自检：能否连上平台、能否读到必要外设、约定的健康检查是否通过。在此之前，任务状态保持“待确认”。自动回滚的条件要事先写明，例如连续若干次启动后仍无法连接，或健康检查明确失败。含糊的“运行不正常”无法在设备侧自动判断。
手动回滚用于观察期内人发现了自动规则覆盖不到的问题。它和自动回滚应进入同一条记录，避免两套操作各改一次槽位。灰度批次若已暂停，已升级且未确认的设备仍要单独决定是确认还是回滚，暂停推送并不会把它们带回去。与状态机结合时，失败、回滚中、已回滚、已确认是不同状态，不能从“升级中”直接跳到“成功”来清掉队列。现场维护若同时在做别的写入，应先停远程维护里的并行任务，再切槽。
单分区设备被当成可秒级切回
把双分区的耗时经验套到单分区上，是批量事故里常见的误判。单分区回滚依赖网络再次下载，弱网设备会长时间停在旧系统已经擦除、新下载尚未完成的窗口。这个窗口里断电，设备可能无法自行启动。此类设备应在升级前确认电量和链路，并保留可本地救砖的手段；平台不能承诺它们与双分区一样可以快速返回。
另一处错误是回滚只切了系统槽，没有处理新版本已经写过的配置或数据。旧系统读到新配置时可能拒绝启动，表现为“回滚后又失败”。任务说明里要写清配置是否随版本走、回滚时恢复哪一份配置备份。只把版本号改回平台记录、设备实际仍跑新版本，监控会按旧版本的规则解释新版本的数据。对账应以设备上报为准，平台记录落后时标成不一致，而不是覆盖上报值。
回滚演练应在小批量上做过一次完整来回：升到新版本、确认未通过、回到旧版本、核对运行版本和关键配置仍可用。没有演练过的机型，不进入允许自动回滚的名单，只允许人工处理。演练记录包含分区类型、旧包是否仍在仓库、回滚后第一次上报的版本号。仓库若实行保留份数上限，应把仍被设备当作回滚目标的版本标成不可删除。误删之后，任务只能显示无法回滚，现场却可能已经擦除了正在运行的槽。自动回滚若连续在同一批次触发，应停止后续批次，而不是让每台设备各自失败后再切回，把影响时间拉长。