ESP32配网失败后怎样恢复？错密码、换路由器和掉电的排查顺序

作者LIU, ZHUOHUI

配网失败应落到一个明确状态，并给用户可执行的下一步。反复重启或清空全部设置可能掩盖原故障，还会增加恢复成本。正确顺序是找到最后一个成功层，再选择有限重试、授权更换凭据或针对性修复。

版本范围：本文按ESP-IDF v5.5配网管理器说明建立恢复设计；v6.0使用独立network_provisioning组件。状态机和故障注入用例均为工程方案，没有报告实机测试结果。

先区分配网成功和业务联网成功

将过程拆成七个观察点：发现设备、安全会话、凭据接受、路由器关联、获取IP、DNS/TLS建立、业务验证。手机提示应对应具体观察点。“设置已收到”“网络已连接”“账号已连接”需要分开表达。

v5.5管理器参考中的已配网状态查询检查是否存有Wi-Fi凭据，不能证明路由器现在可达，也不能证明业务账号有效。因此设备获得IP后云端不可达，应进入业务层恢复，而非自动删除有效网络设置。

凭据试连、网络就绪、业务验证与授权重新配网分离的恢复状态图
原创恢复模型；重试上限、超时和提交策略需要由产品定义。

从最后成功层继续分支排查

分层故障判断表
已有成功证据 下一检查分支
只发现了设备 检查传输连接及认证会话。
设备接受了凭据 检查关联原因、路由器是否存在及配置支持范围。
已关联但没有IP 检查地址获取及网络配置。
有IP但业务不可达 按实际失败顺序检查DNS、路由、时钟、TLS及应用认证。
设备成功而手机超时 检查手机路由、生命周期和最后确认回复。

收集足以复现的最小日志

先固定芯片与模组、固件标识、IDF和配网组件、App构建、手机系统及路由器配置。事件日志至少带启动编号、单调递增序号、相对时间、转换前后状态、尝试次数、驱动或协议错误。配网失败分类与底层Wi-Fi原因要分别保存。

手机和设备通过一次尝试的标识关联，不假定两边时钟已同步。保存最后回复、手机切网和前后台变化。密码、PoP、token及可识别的SSID内容应脱敏；用network-A等稳定标签保留事件关联性，而非把所有网络名都删成无法区分的空白。

错密码和找不到AP分别怎样退出

认证失败应检查凭据及安全兼容性；找不到AP应检查网络是否存在、频段是否支持、可见性和现场条件。单个错误分类未必能证明唯一根因，弱信号也可能造成类似表象，因此需要保留原始原因及扫描、关联事件。

按产品要求设置重试预算和退避；次数耗尽后明确提示，并保留授权纠正入口。重置管理器失败状态、更换已保存凭据、恢复出厂是三种不同动作。给状态迁移绑定具体API前，必须检查所用组件实现。

以下为适用于v5.5/v6.0设计边界的SDK无关伪代码，未编译；其中动作名属于应用责任，并非ESP-IDF接口。

网络尝试结束(结果):
    如果 已获得IP:
        记录网络就绪
        开始业务验证
    否则如果 需要检查凭据:
        提示纠正
        等待授权的新设置
    否则如果 仍有重试预算:
        安排退避重试
    否则:
        提示网络不可用
        保留受控恢复入口

v6.0失败重置与重新配网函数的改名见迁移清单。不要在一个通用回调里同时清空设置、重启服务，却不检查未结束回调和资源所有权。

换路由器时怎样允许重新配网

重连只尝试已有网络；更换网络开启有授权、有限时的配置会话；恢复出厂删除产品明确列出的设置和身份关联。更换路由器的用户通常需要第二种动作，不应不明原因地失去校准、设备所有权或业务参数。

在无互联网、旧路由器消失、手机重启三种条件下验证入口。按键方案要写清按压时间、灯光反馈、取消方式，以及装机后是否仍可触达；App方案要说明云端不可用时如何授权。窗口超时或配置结束都应退出，不能永久暴露配置端点。

配网中掉电后应该回到哪个状态

更换网络跨越收到候选凭据、写入、试连和确认接受等操作。NVS说明讨论了掉电后的存储结构恢复，但不能据此推断整个Wi-Fi、所有权和业务状态组合具有事务保证。

产品可选择试连期间保留上一次可用配置，也可选择替换后在失败时提供本地恢复。标准配网管理器不会自动实现产品专属双槽事务。如果增加这一设计，需要确定唯一的凭据持久化负责人，并核对它与驱动自有存储的关系。

掉电时点与启动后判定标准
中断时点 应满足的行为
候选设置尚未提交 沿已提交状态启动，部分输入不能被认成已接受配置。
已经存储但尚未连接成功 识别未验证候选，执行规定的试连或恢复策略。
网络成功但业务尚未验证 网络状态与账号、服务可用性分别表达。
更新接受标记期间 选出完整可解释的配置，或进入受控配网状态。

仅在指定测试硬件上使用受控电源注入中断。在每个边界附近重复并保留启动日志；一次成功重启不足以覆盖整个提交过程。

检查SoftAP和手机侧造成的假失败

App超时后先看设备时间线。设备可能已连上路由器，而手机离开了无互联网热点、切换接口或进入后台。还要确认状态回复是否仍在队列中，设备就已关闭AP。

将确认、状态查询和热点关闭设计为可观察顺序。证据只支持“结果未知”时，就显示正在核对结果，而不是直接宣布失败。回复丢失也不意味着应立即重发会改变状态的请求。传输指导指出了SoftAP切换问题，具体手机行为仍需实测。

把恢复要求写成可复验的用例

最小恢复验收矩阵
注入故障 可观察的通过条件
首次设置输错密码 可纠正、有限重试，授权后的第二次配置成功。
移除旧路由器 本地入口仍可达，不删除无关状态。
各提交点切断电源 启动状态符合声明的持久化策略。
手机离开热点或切后台 两端最终确认成功、失败或明确的未知结果。
获得IP后DNS或云端失败 保留有效Wi-Fi设置，并指出更高层故障。

每条用例写清初始状态、注入时点、最大重试次数、恢复期限、应保留数据和停止条件。阈值来自产品需求，此处均未测量。归档成功与失败尝试，以及所有人工清理动作。只有全量擦除才能恢复的用例，不算通过原要求。

需要进一步定位时，可向Obeita固件诊断服务提交失败观察点、脱敏事件序列，以及芯片、App、路由器和准确软件版本。

类似文章