适用人群把前四篇全量 / Bootloader / 差分 / 签名都看过的同学读完你能得到一份把四篇串起来的大规模 OTA 上线清单以及一份故障场景 → 怎么扛的对照表。照着做你的 OTA 才敢推给 10 万台设备。一、前四篇各解决了一个问题但量产要全用上篇解决什么不用会怎样OTA_01 全量设备能远程升级A/B 回滚只能抱着线去现场刷OTA_02 BootloaderSTM32 自己跳过去依赖出厂 Bootloader业务绑死OTA_03 差分升级省 80%~95% 流量4G 上每月烧几万到百万OTA_04 签名拒绝非法/篡改固件别人随便给你刷木马但真有 10 万台设备在线时光有这四样还不够版本怎么管理推全量还是灰度网络断了怎么续传一台变砖你能不能发现这篇就是把它们组装成一套可上线的方案并补上前面没展开的运营细节。二、一套完整的大规模 OTA 长啥样┌──────────────────── 服务器 / CI ────────────────────┐ │ 编译 → 签名(OTA_04) → 差分(OTA_03) → 生成版本清单 │ │ 版本清单: {ver, full_url, delta_url(基于上一版), sig} │ │ 灰度策略: 按 device_id 哈希决定谁能升、升到哪版 │ └───────────────────────────┬──────────────────────────┘ │ HTTPS 签名 ┌───────────────────────────┴──────────────────────────┐ │ 设备端每台 │ │ 1. 上报当前版本 设备ID │ │ 2. 问服务器: 我有 v1.2能升到哪版(灰度判定) │ │ 3. 选 full 或 delta(需本地有匹配旧版) │ │ 4. 断点续传下载(Range) 边下边验签(OTA_04) │ │ 5. 写非活跃分区 A/B(OTA_01/02) │ │ 6. 切换启动 自检 mark valid(防回滚) │ │ 7. 上报结果: 成功/失败/回滚 错误码 │ └───────────────────────────────────────────────────────┘四篇的技术全部嵌进第 2~6 步了。下面按主题给可勾选的清单。三、量产 Checklist照着逐条打勾3.1 版本号与防回滚来自 OTA_04 第 6 坑每个固件嵌入单调版本号如0x010002 v1.2写在固定偏移、参与签名设备把已接受的最高版本存eFuse / 写保护 Flash不存普通区升级前比版本服务器版 ≤ 当前版 或 ≤ 最高已接受版 → 直接拒绝杜绝降级攻击新固件启动成功后才更新最高已接受版本和mark valid一起做3.2 灰度发布Canary / 分批绝不 100% 一把推。分级内部 1% → 5% → 20% → 50% → 100%每级之间设健康闸门砖化率 / 崩溃率超阈值如 0.5%→自动熔断暂停谁能升由服务器按hash(device_id) % 100或白名单决定设备端不自己判断保留紧急全量回退开关一键把清单指回旧版3.3 断点续传来自 4G/NB-IoT 必现的断连下载用HTTPRange: bytesN-设备记录已收字节数断线从 N 续不重头下差分场景记录已写到第几个块续传从最后一块继续下载中途断电重启后旧固件完好A/B重新走下载流程即可3.4 安全来自 OTA_04传输走HTTPS明文 HTTP 在生产环境不可接受固件签名验签ECDSA P-256验不过硬拒绝、不下跳公钥锁eFuse/OTP配合 RDP/WRP/PCROP有密钥轮换预案私钥泄露怎么作废、怎么发新公钥固件3.5 A/B 与回滚来自 OTA_01/02新固件未提交状态启动自检 OK 才 mark valid否则自动回滚设回滚计数器连续回滚 N 次 → 放弃本次版本避免无限重启环路看门狗兜底规定时间内没起来 → 复位并回滚3.6 可观测性生产最容易被忘设备上报当前版本、升级结果成功/失败/回滚、错误码服务器端有仪表盘 告警砖化率、失败率突增立即通知这是灰度健康闸门的数据来源——没它你就是瞎推3.7 重试与限流防重启风暴重试用随机退避如随机 1~10 分钟避免 10 万台同时重连把服务器打挂服务器对下发出错峰调度不在业务高峰强推3.8 测试上线前必做断电测试最重要下载中、烧写中各拔电 N 次 → 设备必须不砖、重启能恢复篡改测试下发的固件改 1 字节 → 验签必须拒回滚测试故意发崩溃固件 → 必须自动回旧版canary先在真实设备上小批跑再放大四、设备端主流程把四篇串成一段伪代码voidota_task(void){uint32_tcurread_version();// 当前版本uint32_tmaxread_max_accepted();// eFuse 里的最高已接受版本manifest_tmserver_query(cur,device_id);// 问: 我能升到哪版?(灰度判定)if(m.versioncur||m.versionmax)return;// 防回滚: 不降版本// 选 full 还是 delta: 本地有匹配旧版才用 delta(省流量)constchar*urlhave_old_for(m)?m.delta_url:m.full_url;uint32_treceived0;do{chunk_tchttps_download_range(url,received);// 断点续传if(verify_signature(c.data,c.len,m.sig)!0)// OTA_04 验签return;// 验不过硬拒flash_write_inactive(c.data,c.offset);// OTA_01/02 写非活跃区receivedc.len;}while(!download_done());if(app_is_valid(INACTIVE)set_boot_partition(INACTIVE)OK){esp_restart();// 或 jump_to_app取决于平台}}// 新固件起来后voidapp_main_postboot(void){self_check();// 连服务器/传感器初始化等mark_valid();// 提交, 不再回滚write_max_accepted(read_version());// 更新最高已接受版本(防回滚)report_status(SUCCESS);// 上报, 供灰度闸门判断}这段几乎就是前四篇的总装图防回滚(3.1) 灰度(server_query) 断点(Range) 验签(OTA_04) A/B 写(OTA_01/02) 提交(OTA_01) 全在里面。五、故障场景 → 怎么扛对照表故障会发生什么本文哪条兜住下载中断电旧固件完好A/B(OTA_01) 断点续传(3.3)烧写中断电非活跃区半截激活区(old)仍好app_is_valid 失败 → 仍跑 old(OTA_02)固件被篡改验签失败签名(3.4)中间人下木马验签失败签名 HTTPS(3.4)新固件崩溃未提交 → 自动回滚回滚(3.5)攻击者推旧漏洞版版本号 ≤ 最高已接受 → 拒防回滚(3.1)10 万台同时重试服务器被打挂随机退避 错峰(3.7)新版本有 bug砖化率超阈 → 灰度熔断灰度闸门(3.2) 上报(3.6)六、生产最易翻车的 5 件事#翻车点后果正确做法1没做断电测试大量设备在升级中断电变砖下载/烧写各拔电 N 次必须可恢复2一把推 100%一个 bug 瞬间砖化整 fleet灰度分级 健康闸门3无遥测上报砖化率飙升你不知道设备上报 仪表盘告警4无单调版本号可被降级攻击eFuse 存最高已接受版本(3.1)5回滚无限环路坏固件反复重启耗死设备回滚计数器 看门狗(3.5)七、动手给你的 OTA 做一次自检拿前四篇你写的代码对照第三节 8 张清单逐条打勾。重点问自己三个问题拔一次电设备还能起来吗测断电下个旧版本设备会拒绝吗测防回滚推给 1% 设备你能看到成功/失败数字吗测遥测三问全过才敢说能上线。小结 系列收官五篇 OTA 串起来就是一句话能升级01/02→ 省流量03→ 保安全04→ 能规模运营05。OTA_01 全量升级ESP32OTA_STM32 自写 BootloaderOTA_03 差分升级省流量OTA_04 安全启动与固件签名OTA_05 量产落地 Checklist本篇从让灯闪一下到敢推给十万台设备且半夜不被叫醒你差的不是某一招而是这五篇拼起来的完整闭环。把这系列发出去就是一份含金量很高的我真的懂嵌入式 OTA的作品集。下个方向建议任选① 无线通信系列Wi-Fi 配网 / BLE 透传 / LoRa 入门② RTOS 进阶内存泄漏排查 / 栈溢出定位③ 低功耗系列STM32 Stop 模式 / ESP32 深度睡眠。想写哪个告诉我。