故障恢复与配置保全
本文按2026-10-04开发代码及已有日志复核；OTA自检22项、禁用生命周期，以及RTC/SD/UART恢复相关代码已有局部Host通过记录。r7 Host整组仍失败，定向r11通过也不能代替统一候选或现场验收，未据此部署。现场行为以实际部署版本为准。当前软件没有适用于所有启动故障的独立救援模式。配置备份、网络热点、OTA回滚解决的是不同问题。
先判断发生了什么
| 现象 | 当前可以期待的行为 | 不能据此认定 |
|---|---|---|
| 一个配置文件缺失或无法解析 | 正常存储加载可尝试上一代备份 | 所有字段、引用和接线都正确；主文件已经修复 |
| 存储挂载失败 | 正常启动路径停止，不自动格式化 | 一定还能打开Web页面 |
| 配置迁移显示待重启 | 已准备的受管配置将在下次启动时核验并应用 | 已经生效、外设已正常工作 |
| 迁移冲突/无效/恢复受阻 | 拒绝相应候选；保留状态和恢复材料 | 可以直接删除暂存目录或重复导入 |
| STA暂时离线 | 按配置与运行状态重试；允许时可能回退AP | 所有故障都会出现热点，或原IP一定不变 |
| 内存不足 | 可以暂停部分可选功能并尝试恢复 | 管理页面始终可访问、所有资源都已释放 |
| SD或总线故障 | 返回错误和诊断；部分设备支持明确的恢复操作 | 状态查询会自动修复硬件，或恢复按钮没有副作用 |
| OTA失败 | 可能终止上传会话；是否能回滚取决于实际固件、bootloader、分区和旧镜像 | 升级失败必然自动切回旧版本 |
反复重启会改变现场状态，也可能触发配置回退或清理。先保留首次故障证据，再决定具体恢复动作；不要把格式化、全擦或恢复出厂作为默认第一步。
维护前需要保留什么
- 核对设备MAC/芯片、板卡修订、当前端口或IP、固件与Web版本。设备名称或旧IP不能单独证明找对了设备。
- 保存原始网络、认证/用户、MQTT与平台绑定、外设、规则、屏幕布局及相关文件；记录本次备份覆盖范围和摘要。无法取得的部分明确标为缺失。
- 把包含凭据的原始备份私下保存。公开问题报告只放脱敏信息和摘要；“导出可复用方案”会过滤部分信息，不能替代原始恢复备份。
- 核对接线、供电及负载。重启、重新启用外设或导入启用规则都可能使输出变化；泵阀、电机和其它负载应由现场人员确认安全条件。
- 明确本次允许的操作：只读排查、配置修改、总线恢复、重启或部署。没有确认的动作先保留未执行，不用一次排查授权代替所有后续写入授权。
配置错误与掉电
主配置无法解析时，程序可能加载上一代.bak并尝试恢复主文件。备份能加载只说明该代数据可读，不说明所有业务配置有效，也不保证主槽恢复成功。应保存相关日志，并在授权修复后核对文件、运行状态及下一次启动。
主文件和备份都不可用时，各模块的处理方式不同。网络还会尝试部分NVS备份，仍无可用配置时可能使用默认设置；不存在“任意配置都会自动回到上次完整可用状态”的保证。
临时文件与备份提交能降低写入中断的风险，但不能保证任何掉电都无损。部分非关键配置可能先进入延迟写入缓存；存储硬件故障、空间不足、未完成写入和多个文件之间的不一致仍需排查。“页面保存成功”“已提交磁盘”“已应用”应分别核实。
普通逐文件导入与受管跨文件迁移是不同入口。前者后续文件失败时，前面的文件可能已经保存；后者使用已审阅的会话和候选摘要，在启动时应用有限的一组配置。两者都不是整个Flash或固件的自动回滚。
受管迁移怎样确认恢复
使用设备配置中的迁移状态和确认流程。准备成功后仍须核对重启后的状态、目标身份及实际配置；请求超时或最后响应丢失时，先查询，不能直接重放整包。
若界面明确提供可清理或可隔离的暂存，应先核对该会话/修订及保全材料，再执行对应确认。隔离只适用于程序识别的暂存形态，不代表任意坏配置都能安全隔离。应用中或恢复受阻的事务不可用普通清理代替恢复；启动已被阻止时，Web可能无法提供该操作，需要具体离线维护方案。
此迁移入口保留设备身份和账号绑定；网络、协议是只读依赖，用户与认证文件不在可写范围中。普通导入和直接文件写入不自动具有相同保证。
网络恢复的特殊边界
有STA凭据且配置不允许自动回退时，设备的相关重试路径会继续STA恢复，不一定创建热点。热点名称、地址及是否可用应按实际配置和现场证据确认，不能只根据旧文档猜测。
源码另有最后保障AP路径：只有该AP也启动失败时才累加网络初始化失败计数；达到阈值后会尝试清理网络专用NVS备份并重启。这不删除LittleFS中的网络主文件和.bak，也不是全设备恢复出厂。NVS写入失败时，实际持久计数可能与日志意图不同。有效JSON仍可能在下一次启动优先加载，因此不能认为该计数一定修复坏网络配置。
修改网络前保留原始网络配置与可恢复的管理入口；掉线后先确认当前MAC/IP及路由状态，不以重复改SSID、清配置或频繁重启试错。
OTA与启动失败
上传型OTA有停滞会话清理：相关检查入口发现60秒没有新块后记录失败并清理会话状态。升级分区可能已经写入部分字节，这不是“从未写入”的证明，也不能代替当前启动镜像核验。
开发候选已接入NEW/PENDING_VERIFY两种待确认状态，保留90秒应用运行窗口；重复启动检查不会刷新窗口。到期确认最多3次、间隔5秒，SDK失败耗尽仍保留未确认状态，不自动重启。关键初始化失败时先保存诊断，再尝试标记新版本无效；SDK失败不自动重启，成功后才明确重启。这22个场景已在r7 Host日志局部通过，但Host整组仍失败，不能视为设备已部署或已具备经过验收的回滚行为。
90秒只是应用运行窗口，不是全硬件自检。实际回滚还依赖bootloader、可用升级分区和有效旧镜像；4MB单应用等布局不能据其它板型经验推定支持。不要只改一个配置项或照抄旧镜像就认定具备救援能力。
正常启动若在存储或迁移恢复阶段失败，网络和Web可能尚未建立。遇到这种情况，应保留证据并制定与该设备、分区及配置备份一致的维护方案。任何重新刷写都须明确目标和保留范围，不能先全擦后补做备份。
SD与总线恢复
SD状态查询不自动重挂载。明确恢复操作可能卸载、释放并重新取得SPI资源，且会实际访问介质；确认卡、供电、所属外设和共享总线后再操作。失败后保留原错误与计数，不连续点击恢复来制造新的干扰。
I2C重新初始化只覆盖软件总线入口，不保证解除电气拉低或修复所有共用设备。busy、未知或待清理表示尚未确认完成；不能据配置已禁用就断言输出已停止或资源已释放。其它总线和输出按各自设备文档核验。
RTC、UART与诊断采样
RTC访问及35启停、36日历读取、37显式复制系统本地时间已有实现；日历、系统来源质量和断电保持是不同证据。时间来源失效后需要新的有效同步记录，不能靠刷新状态恢复旧记录；复制动作不主动请求NTP，写后失败也可能已改变RTC。实际校时与断电保持仍为 NOT_RUN，见DS1302 RTC。
通用UART已有控制器租约与接收代际，每次真实重新初始化会建立新接收流；停用、重建或来源无法确认时，相关规则停止余项，已发出的数据不撤回。本地初始化/发送成功不是对端成功或故障已恢复。真实收发、硬件溢出和长期恢复仍为 NOT_RUN，见UART示例。
系统信息/诊断包已有分池内存快照，资源状态可显示busy、retiring等未完成状态；开发者单次任务栈快照也已有受限入口。这些接口不会自动做功能启停或故障恢复实验，重叠内存池不能相加，缺失数值不是零；任务栈采样可能影响调度。六组功能状态、资源释放/恢复及峰值仍须实机测量，当前为 NOT_RUN，具体接口与权限见系统健康监控。
什么才算恢复完成
2026-10-04开发候选另外修复关闭OTA的C6配置链接缺少管理器析构的问题：禁用配置仍不创建OTA服务，启用时的资源退出顺序保持。真实禁用翻译单元链接回归已在r7 Host局部通过，目标构建与实际启动仍须按同候选证据确认；此项不是设备回滚/救援能力已验收或现场固件已更新。
配置恢复应核对保存内容、目标身份、管理网络、认证、MQTT、布局和相关文件，随后验证业务行为。部署必须有本次制品的写入及独立校验证据，不能复用旧报告。API读回、物理动作、故障恢复和长时间稳定性分别记录。
保留最初的失败和恢复过程。恢复后的短时正常不能抹去之前的中断，也不能当作24小时或7天稳定性通过。本文涉及的实际设备、故障注入、物理恢复、内存测量及长稳项目仍为 NOT_RUN。