阅读导航#

1. 杰理 AC79 应用启动与注册机制详解：从 REGISTER_APPLICATION 到 start_app
2. paipopAi 对话玩具解析（一）：从 APP_STA_START 到眼睛任务与摇一摇服务
3. paipopAi 对话玩具解析（二）：从按键与摇一摇到对话打断
4. paipopAi 对话玩具解析（三）：从按键启动到云端语音回答
5. paipopAi 对话玩具解析（四）：PaipopSDK 如何封装 LingXinSDK
6. paipopAi 对话玩具解析（五）：AI 播放时如何实现自然语音打断
7. 本文：从开机自动联网、失败回退到 AP 网页配网。
8. paipopAi 对话玩具解析（七）：从版本检查到双备份 OTA 安全升级

本文范围与证据边界#

本文基于独立正式发布仓库 Paipop_YP_Toy_release_v128 的 main@24a83f9，产品版本为 V1.2.8 / 10208，目标平台为杰理 AC791N/WL82。

本次采用静态源码复核，没有重新烧录设备，也没有采集新的路由器报文或串口日志。因此需要区分以下证据强度：

本文涉及的代码归属如下：

一、先建立全局图：联网不是一个函数，而是一组异步协作#

如果只看应用启动代码，联网似乎只有一行：

1
paipop_wifi_provision_start();

但这行代码并不会同步完成“扫描、关联、DHCP、连接云端”全部工作。它只做三件事：

1. 清空 Wi-Fi 策略层上下文；
2. 向杰理 Wi-Fi 模块注册事件回调；
3. 如果 Wi-Fi 尚未开启，则调用 wifi_on()。

后续流程由 Wi-Fi 模块异步回调驱动：

1
APP_STA_START
2
    │
3
    └─ paipop_wifi_provision_start()
4
           │
5
           ├─ wifi_set_event_callback(callback)
6
           └─ wifi_on()
7
                  │
8
                  ├─ WIFI_EVENT_MODULE_INIT
9
                  ├─ WIFI_EVENT_MODULE_START
10
                  ├─ WIFI_EVENT_STA_START / AP_START
11
                  ├─ WIFI_EVENT_STA_CONNECT_SUCC
12
                  └─ WIFI_EVENT_STA_NETWORK_STACK_DHCP_SUCC

Wi-Fi 回调再把产品真正关心的结果投递给杰理系统事件框架：

1
杰理 Wi-Fi 回调
2
→ paipop_apcfg_notify_net()
3
→ net_event_notify()
4
→ SYS_NET_EVENT
5
→ paipop_toy_event_handler()
6
→ paipop_events_handle_sys_event()
7
→ paipop_events_handle_net()
8
→ paipop_fsm_dispatch()

这条链中存在一次明确的异步边界：Wi-Fi 回调只报告结果，产品状态迁移最终在应用事件路径中完成。

这样做的意义是，底层 Wi-Fi 模块不需要知道“闭眼、播放提示音、退出语音会话、初始化 PaipopSDK”等产品规则。

二、项目里其实有两个状态机#

阅读这部分源码时，最容易犯的错误是把 PAIPOP_APCFG_* 和 PAIPOP_TOY_STATE_* 当成同一套状态。

它们回答的是不同问题。

1
enum paipop_apcfg_state {
2
    PAIPOP_APCFG_IDLE = 0,
3
    PAIPOP_APCFG_AP,
4
    PAIPOP_APCFG_STA_CONNECTING,
5
    PAIPOP_APCFG_STA_READY,
6
};

1
VM_CONFIG
2
AP_CONFIG
3
ENGINE_INIT
4
ENGINE_INIT_FAILED
5
ENGINE_CHAT
6
ENGINE_EXIT

三、应用启动后，为什么先进入 VM_CONFIG#

paipop_fsm_init() 把产品初始状态设置成：

1
fsm.state = PAIPOP_TOY_STATE_VM_CONFIG;

这里的 VM 指杰理 SDK 用于保存 Wi-Fi 模式和凭据的非易失存储机制。它不表示虚拟机，也不代表设备一定已经有可用凭据。

应用启动顺序中，FSM 先初始化，随后才启动 Wi-Fi：

1
paipop_fsm_init()
2
→ 初始状态 VM_CONFIG
3

4
paipop_wifi_provision_start()
5
→ 注册 Wi-Fi 回调
6
→ wifi_on()

因此产品从一开始就处于“等待历史网络结果”的业务状态。底层之后报告成功、失败或没有历史凭据，事件层才能把它转换成对应 FSM 事件。

四、为什么能保存 6 组，却只自动连接 1 组#

当前常量是：

1
#define PAIPOP_APCFG_VM_MAX_STA 6

Wi-Fi 初始化时还会调用：

1
wifi_set_store_ssid_cnt(PAIPOP_APCFG_VM_MAX_STA);

这表示杰理原生 Wi-Fi VM 最多保留 6 组不同 STA 凭据。

但“能保存 6 组”和“启动时自动尝试 6 组”是两回事。

启动路径调用 paipop_apcfg_load_last_vm_sta()，而该函数只把最近一次成功凭据复制到：

1
apcfg.vm_sta[0]

随后明确设置：

1
apcfg.vm_sta_count = 1;
2
apcfg.vm_sta_index = 0;

因此自动连接策略是：

1
读取最近一次成功网络
2
→ 最多尝试这一组
3
→ 成功则继续
4
→ 失败则进入 AP 配网

其余最多 5 组历史记录并没有丢失，它们只用于配网页面中的人工选择。

这是当前 V1.2.8 的明确产品取舍。早期版本曾经尝试扫描和遍历多个历史网络，但当前实现删除了这条复杂路径，以减少扫描阻塞、重复重连和异步事件竞态。

优点是状态简单、失败时间可预测；缺点是用户换到另一个曾连接过的地点时，设备不会自动尝试更早记录，需要主动进入配网页面选择。

五、WIFI_EVENT_MODULE_INIT 决定第一次启动模式#

Wi-Fi 模块初始化完成后，回调处理 WIFI_EVENT_MODULE_INIT。

这一分支先完成公共参数设置：

1
最多保存 6 组 SSID
2
STA 连接超时 20 秒
3
根据 MAC 生成设备 AP 名称
4
刷新历史记录缓存

随后分成两条路径。

1
default_info.mode = STA_MODE;
2
default_info.connect_best_network = 0;

1
default_info.mode = AP_MODE;

1
PAIPOP_NET_EVENT_AP_CONFIG

1
PAIPOP_EVT_VM_ALL_FAILED

六、为什么“关联成功”还不能算真正联网#

连接路由器至少可以拆成两个重要阶段：

1
STA 关联成功
2
→ WIFI_EVENT_STA_CONNECT_SUCC
3

4
DHCP 成功
5
→ WIFI_EVENT_STA_NETWORK_STACK_DHCP_SUCC

STA_CONNECT_SUCC 只能证明设备已经完成 802.11 关联。此时设备未必已经取得 IP、网关和 DNS 配置，也就未必能访问云端。

当前代码在 WIFI_EVENT_STA_CONNECT_SUCC 中只记录信道，不通知产品联网成功。

真正的成功边界放在 DHCP 成功事件：

1
apcfg.state = PAIPOP_APCFG_STA_READY;
2
paipop_apcfg_store_sta_if_needed();
3
paipop_apcfg_notify_net(NET_EVENT_CONNECTED);
4
paipop_ota_network_ready();

也就是说，以下三件事发生在同一业务边界之后：

1. 允许保存本次成功凭据；
2. 通知产品 FSM 网络已连接；
3. 通知 OTA 模块网络已就绪。

这是很重要的工程原则：

不要把链路层关联成功当作应用层网络可用。至少要等 DHCP 成功；更严格的产品还可以增加 DNS、网关或服务端探活。

当前项目验证到 DHCP 边界，没有在这里额外访问云端健康检查接口。

七、为什么新密码必须等 DHCP 成功后再写入 VM#

网页提交新的 SSID 和密码后，代码不会立即调用 wifi_store_mode_info()。

它只做：

1
apcfg.pending_save = 1;
2
wifi_enter_sta_mode(apcfg.pending_ssid, apcfg.pending_pwd);

只有后续收到 DHCP 成功事件，paipop_apcfg_store_sta_if_needed() 才真正保存。

如果提交后立即保存，会产生一个典型故障：

1
用户输错密码
2
→ 错误凭据被写成“最近成功网络”
3
→ 本次连接失败
4
→ 设备重启后再次自动尝试错误凭据
5
→ 用户持续陷入失败流程

延迟保存把“用户提交”与“凭据验证通过”分开：

1
提交只是候选
2
DHCP 成功才转正

这种 pending/commit 两阶段思路也常见于配置文件替换、OTA 元数据和数据库事务。

八、MRU 历史记录是怎样维护的#

MRU 即 Most Recently Used，最近使用的记录排在前面。

当前保存函数先删除同名 SSID，再重新写入：

1
wifi_del_stored_sta_info((char *)ssid);
2
wifi_store_mode_info(STA_MODE, (char *)ssid, (char *)pwd);

这样做解决两个问题：

• 相同 SSID 更换密码时，不会生成重复项；
• 再次成功使用某个旧网络时，可以把它更新为最近记录。

读取全部历史时，paipop_apcfg_load_stored_sta_list() 还会：

1. 限制最多读取 6 条；
2. 丢弃空 SSID；
3. 按 SSID 去重；
4. 必要时回退到“最后记忆模式”接口；
5. 调用 paipop_apcfg_order_sta_mru() 统一成最近优先顺序。

order_sta_mru() 处理了杰理接口可能返回“旧到新”或最近记录位于中间的情况：如果最近记录在数组末尾，就整体反转；如果位于其他位置，就把它移动到首位并保持其余记录的相对顺序。

这里需要谨慎表述：源码可以验证项目怎样归一化和重新保存，底层 VM 具体采用什么擦写、磨损均衡和掉电保护策略，则位于杰理 SDK 内部边界，本文不做推断。

九、自动联网失败如何进入产品事件系统#

以下失败都会被 Wi-Fi 回调接收：

• 找不到目标 SSID；
• 关联失败；
• 关联超时；
• DHCP 超时；
• 强制模式超时。

回调不会直接播放声音或操作眼睛，而是调用：

1
paipop_apcfg_sta_fail_to_ap(reason, net_event);

该函数清理自动连接候选，把局部状态退回 IDLE，再通过 paipop_apcfg_notify_failure_once() 发布网络事件。

事件经过 SYS_NET_EVENT 到达 paipop_events_handle_net() 后，会依据产品当前状态二次翻译：

同一个底层失败在不同业务阶段含义不同，这就是为什么事件层必须读取 FSM 当前状态，而不能把错误码机械地一一映射。

十、为什么需要 failure_notified#

一次真实连接失败可能伴随多个底层事件，例如先出现关联失败，随后又出现强制模式超时。

如果每个事件都向产品层上报，可能发生：

1
第一次失败
2
→ 播放配网提示
3

4
第二次迟到失败
5
→ 再次清 pending
6
→ 重复播放或重复切换 AP

因此代码用：

1
u8 failure_notified;

保证一个连接尝试只上报一次失败。新的连接尝试开始或 DHCP 成功后，再把它清零。

这不是消灭底层重复事件，而是在策略层建立幂等边界。

十一、为什么提示音结束后才迁移状态#

自动连接失败后，产品不是立即切入 AP_CONFIG，而是调用：

1
paipop_fsm_play_then_transition(
2
    PAIPOP_TONE_NET_CONFIG,
3
    PAIPOP_TOY_STATE_AP_CONFIG,
4
    PAIPOP_EVT_VM_ALL_FAILED);

该函数先把目标状态记录到：

1
fsm.pending_after_tone

然后播放 NetCfgStart.mp3。

音频结束后，paipop_tone.c 发布 PAIPOP_EVT_TONE_DONE；FSM 取走 pending 目标并完成迁移：

1
VM_ALL_FAILED
2
→ pending_after_tone = AP_CONFIG
3
→ 播放 NetCfgStart.mp3
4
→ AUDIO_SERVER_EVENT_END
5
→ PAIPOP_EVT_TONE_DONE
6
→ take_pending()
7
→ transition(AP_CONFIG)

如果提示音文件打不开或播放器启动失败，代码会清掉 pending 并直接迁移，保证用户不会因为提示音资源损坏而永远无法配网。

这体现了一个可靠性原则：提示音是用户体验步骤，不应成为核心状态迁移的单点故障。

十二、AP 热点是怎样生成的#

进入 AP 模式时，SSID 前缀固定为：

1
JL_AI_TOY_

后缀取设备 MAC 地址的最后两个字节，形成类似：

1
JL_AI_TOY_ABCD

这样同一环境里多台设备不至于全部重名。

当前 AP 密码为空：

1
#define PAIPOP_APCFG_AP_PWD ""

局域网固定配置为：

1
设备地址：192.168.1.1
2
子网掩码：255.255.255.0
3
网关：192.168.1.1
4
首个客户端地址：192.168.1.2
5
DNS：192.168.1.1

设备通过 DHCP Server 告诉手机：“DNS 服务器也是 192.168.1.1”。这是后续强制门户能够工作的基础。

十三、手机为什么可能自动弹出配网页面#

手机连接一个 Wi-Fi 后，系统通常会访问自己的联网探测地址，例如：

1
/generate_204
2
/gen_204
3
/hotspot-detect.html
4
/library/test/success.html
5
/connecttest.txt
6
/ncsi.txt
7
/redirect

如果收到预期的互联网响应，系统认为该 Wi-Fi 可以正常上网；如果被重定向或收到登录页面，系统可能弹出强制门户窗口。

Paipop 在 AP 模式下做了两层拦截：

1
任意域名 DNS 查询
2
→ 解析到 192.168.1.1
3

4
常见联网探测 HTTP 请求
5
→ 直接返回 Paipop 配网页面

其他普通 GET/HEAD 请求则返回：

1
HTTP/1.1 302 Found
2
Location: http://192.168.1.1/

因此无论系统探测哪个常见域名，最终都有机会访问玩具本地页面。

但必须强调：

设备只能尽量满足常见强制门户协议，是否自动弹窗由 Android、iOS、Windows 的版本、缓存和安全策略决定。手动访问 http://192.168.1.1 才是确定的备用入口。

十四、通配 DNS 服务具体做了什么#

paipop_apcfg_dns_task() 创建一个 UDP socket，绑定本地 53 端口。

收到 DNS 包后，paipop_apcfg_dns_build_response() 只处理一个问题，并验证域名标签长度和报文边界。

对于 IN 类的 A 或 ANY 查询，它返回：

1
Answer = 192.168.1.1
2
TTL = 30 秒

对于其他查询类型，则返回“成功但没有答案”，让客户端有机会回退到 IPv4 A 查询。

这不是完整的通用 DNS 服务器，而是一个针对强制门户的最小实现。它没有递归查询公网 DNS，也不需要知道请求的真实域名。

DNS 任务使用独立线程 paipop_ap_dns；停止时先把 dns_running 清零，再让 socket 退出阻塞，最后 thread_kill(..., KILL_WAIT) 等待线程结束。

十五、HTTP 配网服务为什么设计得很小#

paipop_apcfg_http_task() 创建 TCP 监听 socket：

1
地址：0.0.0.0
2
端口：80
3
listen backlog：1
4
单次请求缓冲：1460 字节

它串行接受连接，每次只读取一块请求并处理以下路径：

这种实现资源占用小、依赖少，适合 MCU 临时配网页面；它不是高并发、完整兼容 HTTP/1.1 的 Web 服务器。

由此也能看出边界：代码一次 sock_recv() 就尝试解析完整请求，没有实现分片 body 累积、chunked encoding 或长连接。因此页面表单很小且由本机生成时通常够用，但复杂客户端或网络分片场景需要专项验证。

十六、8 KiB 动态页面为什么还有降级版本#

带历史网络列表的页面使用：

1
calloc(1, 8192)

动态拼接 HTML。

嵌入式设备可能因为堆碎片或瞬时内存不足导致分配失败，也可能因为异常 SSID 造成页面拼接空间不足。因此代码准备了一个不包含历史下拉框的静态手动输入页面。

1
动态页面分配成功
2
→ 展示历史 Wi-Fi + 手动输入
3

4
动态页面分配失败或溢出
5
→ 返回静态手动输入页面

这是一种功能降级策略：历史选择是增强功能，手动输入才是配网核心能力。

十七、为什么历史 SSID 要做 HTML 转义#

SSID 是外部输入，可能包含：

1
&  <  >  "  '

如果直接拼进 <option>，轻则页面结构损坏，重则产生本地 HTML 注入。

paipop_apcfg_html_escape() 会把这些字符转换为实体，同时把控制字符转换成数字实体。

这说明即使页面只运行在设备本地热点中，也不能把路由器广播的 SSID 当成可信字符串。

代码还给转义后的单个 SSID 预留 225 字节，避免原始字符串经过实体扩展后写越界。

十八、历史密码为什么不会进入网页#

历史页面只输出 SSID 和数组索引：

1
<option value="0">HomeWiFi</option>

不会把密码写进 HTML、JavaScript、HTTP 响应或普通日志。

当用户选择历史网络时，表单提交：

1
history = 0..5
2
snapshot = 当前历史快照编号

设备端再根据索引从 apcfg.history_sta[] 读取内部密码。

这比把密码放进隐藏 input 安全得多，因为隐藏字段依然会被浏览器看到并通过网络传输。

手动输入新网络时：

1
history = -1
2
ssid = 用户输入
3
password = 用户输入

两种模式复用同一个 /config 处理入口。

十九、history_snapshot 防的是什么问题#

只提交历史数组索引还不够安全。

假设用户打开页面时：

1
index 0 = Home
2
index 1 = Office

随后设备刷新历史顺序，可能变成：

1
index 0 = Office
2
index 1 = Home

如果旧页面此时提交 history=0，设备就会连接错误网络。

因此每次刷新历史缓存，代码都会增加：

1
apcfg.history_snapshot

页面同时提交 index 和 snapshot。服务端只有在以下条件全部满足时才接受：

• snapshot 与当前缓存一致；
• index 没有越界；
• 对应 SSID 非空。

否则返回 HTTP 400：

1
history selection is invalid or expired

这相当于给数组索引附加一个轻量版本号，避免陈旧 UI 引用已经改变的后端状态。

二十、收到表单后为什么先响应，再切 Wi-Fi#

解析成功后，HTTP 任务先保存候选配置并向手机返回“已收到 Wi-Fi 信息”的页面。

关闭客户端连接之后，任务才延迟少量 OS tick 并执行 STA 切换。

如果先关闭 AP 或立即切到 STA，手机到玩具的连接会被断开，HTTP 成功页面可能来不及完整发送，用户只会看到浏览器报错。

所以顺序是：

1
接收并校验表单
2
→ 复制到 pending_ssid/pending_pwd
3
→ 返回 HTTP 200
4
→ 关闭客户端与监听服务
5
→ 短暂让出执行时间
6
→ 停止 captive DNS
7
→ 切换到目标 STA

源码使用 os_time_dly(20)；其精确墙上时间取决于系统 tick 配置，不能仅凭参数 20 就断言一定是 20 ms 或 200 ms。

二十一、为什么切换 STA 前还要修改 default_info#

网页提交新网络后，代码不只是调用：

1
wifi_enter_sta_mode(new_ssid, new_pwd);

它还先构造 wifi_store_info，把内存中的强制默认 STA 改成新 SSID，再调用 wifi_set_default_mode()。

源码注释给出了原因：杰理 Wi-Fi 驱动可能仍在重试开机时的默认 SSID。如果只调用切换接口，第一次扫描过程中旧默认网络可能重新取得控制权。

因此当前顺序是：

1
关闭 DNS
2
→ 清除旧自动连接候选
3
→ 禁止 best-SSID 策略
4
→ 清空扫描结果
5
→ 把内存默认 STA 指向新凭据
6
→ wifi_enter_sta_mode(new)

这是一个典型的异步驱动竞态修复：不能只发“连接新网络”命令，还要清理旧策略可能留下的控制输入。

二十二、配网失败后怎样回到 AP#

用户提交的新网络如果找不到、密码错误或 DHCP 失败，Wi-Fi 层发布连接失败事件。

此时产品已经处于 AP_CONFIG，所以事件层把错误翻译为：

1
PAIPOP_EVT_AP_CONNECT_FAILED

FSM 的处理是：

1
播放 NetCfgFail.mp3
2
→ 调用 paipop_wifi_provision_enter_ap()
3
→ 清空失败的 pending 凭据
4
→ 刷新历史缓存
5
→ 重设 AP 默认模式
6
→ wifi_enter_ap_mode()
7
→ AP_START 后重启 DNS 与 HTTP

这里的失败提示音使用 notify_done=0，也就是不等待提示音结束才恢复 AP。它告诉用户本次配置失败，但不会把恢复配网能力依赖在提示音完成事件上。

二十三、运行时断网会清理哪些业务状态#

设备已经取得 DHCP 后，如果收到 WIFI_EVENT_STA_DISCONNECT，Wi-Fi 服务会：

1. 通知 OTA 网络已断开；
2. 把局部状态从 STA_READY 退回 IDLE；
3. 发布 NET_EVENT_DISCONNECTED。

事件进入 FSM 后，清理范围很广：

• 取消按住说话状态；
• 清除初始化期间锁存的点击；
• 清除按键打断提示；
• 清除摇一摇打断；
• 清除旧轮重启请求；
• 清除 30 秒无输入窗口；
• 取消预录 PCM；
• 清空提示音后的 pending 状态；
• 停止当前提示音；
• 如果正在聊天，请求退出当前对话。

随后产品进入 VM_CONFIG，重新读取最近一次成功凭据并尝试连接。

这说明断网不是单纯把一个 connected 布尔值改为 0，而是一次跨音频、会话、提示音和 OTA 的资源收敛过程。

二十四、为什么 AP_CONFIG 收到断网不能回 VM_CONFIG#

状态迁移校验明确规定：

1
target == VM_CONFIG

时，当前状态不能是 AP_CONFIG。

原因是 AP 配网本身就会经历模式切换、手机离开热点、STA 连接失败等网络变化。如果每次 NET_DISCONNECTED 都把产品切回 VM 自动连接，就可能形成振荡：

1
AP 配网
2
→ 模式切换产生断网
3
→ 回 VM
4
→ 最近凭据失败
5
→ 再回 AP
6
→ 再产生断网

所以 AP 状态收到断网时只做：

1
清 pending
2
→ 停提示音
3
→ 闭眼
4
→ 重新进入 AP

产品状态仍保持 AP_CONFIG。

这是一条业务硬约束：

AP 配网只能因真正获得 DHCP 成功而离开，不能被普通断网事件带回自动连接流程。

二十五、双键长按怎样触发主动配网#

K1、K2 是低电平有效 GPIO。事件服务每 20 ms 在 app_core 任务中读取一次两个引脚。

双键同时保持约 3 秒后：

1
combo_key.fired = 1
2
→ 设置两个按键的 click 抑制掩码
3
→ paipop_events_post(PAIPOP_EVT_FORCE_AP_CONFIG)

释放按键后，普通点击抑制最多保留 500 ms，避免一次“双键长按”又被解释成两个普通点击，从而误启动语音对话。

如果单键长按正在进行麦克风回环测试，第二个键按下后会先取消回环，因为手势已经从“单键测试”升级成“双键配网”。

OTA 忙时，组合键计时会被清零，主动配网不会触发，避免升级写入期间切换网络。

二十六、force_ap_pending 怎样隔离迟到事件#

主动配网可以从任意业务阶段发生，包括：

• 正在连接旧 Wi-Fi；
• 正在初始化语音引擎；
• 正在录音或播放 AI 回答；
• 正处于空闲等待。

FSM 收到 PAIPOP_EVT_FORCE_AP_CONFIG 后，第一步不是立即调用 wifi_enter_ap_mode()，而是：

1
paipop_wifi_provision_prepare_force_ap();

该函数设置：

1
apcfg.force_ap_pending = 1;

并清除旧 STA 候选与待保存凭据。

之后 FSM 清理对话相关状态，必要时请求退出当前聊天，播放进入配网提示音；提示音结束后才真正迁移到 AP_CONFIG 并切 AP。

为什么不先切 AP？因为 STA 切 AP 会产生断网事件，而普通断网处理会停止当前提示音并转入 VM 流程。

force_ap_pending 建立了一段保护期：

1
用户已经决定强制配网
2
→ 旧 STA 的成功、失败、DHCP、断开事件陆续到达
3
→ Wi-Fi 回调和事件层检查 force_ap_pending
4
→ 忽略与新意图冲突的旧事件
5
→ AP_START 后清除保护标志

这与第五篇中的 generation、phase gate 思想相同：异步系统无法阻止旧事件已经在路上，只能给新流程建立身份或意图门禁。

二十七、网络事件为什么还会取消麦克风回环#

paipop_events_handle_net() 在处理任何网络状态变化前都会：

1
paipop_mic_loopback_cancel();
2
paipop_mic_loopback_stop_playback();

麦克风回环是本地测试模式，会占用录音或播放资源。网络变化可能启动语音引擎、提示音、配网流程或会话清理，如果保留回环就可能与这些音频资源冲突。

因此网络事件不仅改变 Wi-Fi 状态，也被当成“退出诊断音频模式”的统一边界。

二十八、DNS、HTTP、Wi-Fi 回调分别运行在哪里#

这条链并不是单线程顺序执行：

共享的 apcfg 结构同时保存状态、socket、线程 PID、历史缓存和候选密码。

当前代码没有为整个 apcfg 增加统一 mutex，而是主要依赖以下时序约束：

• 刷新历史前先停止 HTTP/DNS；
• HTTP 接受配置后自行退出监听循环；
• 停止线程时让 socket 退出阻塞并等待线程结束；
• force_ap_pending 屏蔽切换期旧回调；
• failure_notified 保证失败上报幂等。

这种实现节省同步开销，但维护时必须小心新增跨线程读写。如果以后让网页支持刷新、并发请求或后台扫描历史网络，就应重新审查共享字段的同步和对象生命周期。

二十九、当前实现的安全边界与不足#

这一部分面试时不能回避。

三十、当前实现还有哪些工程限制#

三十一、三条完整调用链#

1
APP_STA_START
2
→ paipop_fsm_init(): state = VM_CONFIG
3
→ paipop_wifi_provision_start()
4
→ wifi_set_event_callback()
5
→ wifi_on()
6
→ [callback] WIFI_EVENT_MODULE_INIT
7
→ 读取最近成功 STA
8
→ wifi_set_default_mode(STA, force=1, store=0)
9
→ [callback] WIFI_EVENT_STA_START
10
→ [callback] WIFI_EVENT_STA_CONNECT_SUCC
11
→ [callback] WIFI_EVENT_STA_NETWORK_STACK_DHCP_SUCC
12
→ 保存/置顶成功凭据
13
→ net_event_notify(NET_EVENT_CONNECTED)
14
→ [系统事件队列]
15
→ paipop_events_handle_net()
16
→ paipop_fsm_dispatch(PAIPOP_EVT_NET_CONNECTED)
17
→ pending_after_tone = ENGINE_INIT
18
→ 播放 NetCfgSucc.mp3
19
→ [audio_server 回调]
20
→ PAIPOP_EVT_TONE_DONE
21
→ transition(ENGINE_INIT)
22
→ paipop_engine_chat_init()

1
WIFI_EVENT_MODULE_INIT
2
→ 没有历史 STA
3
→ 默认模式设为 AP
4
→ 发布 PAIPOP_NET_EVENT_AP_CONFIG
5

6
或者
7

8
STA 关联/DHCP 失败
9
→ notify_failure_once(error)
10

11
共同进入
12
→ SYS_NET_EVENT
13
→ PAIPOP_EVT_VM_ALL_FAILED
14
→ 播放 NetCfgStart.mp3
15
→ TONE_DONE
16
→ transition(AP_CONFIG)
17
→ paipop_wifi_provision_enter_ap()
18
→ WIFI_EVENT_AP_START
19
→ 启动 paipop_ap_dns
20
→ 启动 paipop_ap_http
21
→ 手机打开配网页面

1
POST /config
2
→ 解析 history/snapshot 或 ssid/password
3
→ 校验历史选择是否过期
4
→ 复制 pending_ssid/pending_pwd
5
→ 返回 HTTP 200
6
→ 关闭 HTTP 连接和监听
7
→ 停止 DNS
8
→ 清旧扫描/旧默认 STA 控制
9
→ wifi_enter_sta_mode(new)
10
→ 关联成功
11
→ DHCP 成功
12
→ 保存新凭据并置为 MRU
13
→ NET_EVENT_CONNECTED
14
→ 播放联网成功提示音
15
→ ENGINE_INIT

三十二、关键函数身份与职责#

三十三、这部分最值得面试讲的六个设计点#

三十四、面试官可能继续追问什么#

三十五、怎样用一分钟讲清楚#

这个项目没有把联网写成一个阻塞函数，而是给杰理 Wi-Fi 模块注册回调，由策略层处理模块启动、STA 关联、DHCP、AP 和超时事件，再通过 SYS_NET_EVENT 交给产品 FSM。设备最多保存 6 组历史 Wi-Fi，但开机只自动连接最近一次成功网络，20 秒内关联或 DHCP 失败就进入 AP 配网，避免多网络扫描造成长等待和重复事件。关联成功还不算联网，只有 DHCP 成功后才保存候选密码、通知 FSM 和 OTA。AP 使用 MAC 后缀生成名称，在 192.168.1.1 上运行最小通配 DNS 和 HTTP 服务，让手机尽量自动弹出配网页面。历史页面只输出转义后的 SSID，密码留在设备内部，并用 snapshot 防止旧页面索引连错网络。用户双键长按 3 秒可以从任意状态强制配网，force_ap_pending 会屏蔽旧 STA 迟到的成功、失败和断开事件。整个设计的重点是把底层异步网络事件、用户提示流程和语音引擎生命周期分层处理。

三十六、源码证据索引#

总结#

Paipop 的联网与配网可以分成五层：

1
无线执行层
2
杰理 Wi-Fi 模块 + STA/AP + DHCP
3

4
策略层
5
最近凭据选择 + pending 保存 + MRU + 失败去重
6

7
本地门户层
8
通配 DNS + HTTP 页面 + 历史 snapshot
9

10
事件桥接层
11
Wi-Fi callback → SYS_NET_EVENT → Paipop 业务事件
12

13
产品控制层
14
FSM + 提示音门控 + 语音/OTA/预录清理

最值得记住的不是某个 Wi-Fi API 名字，而是三个边界：

1. 关联成功不等于网络可用，当前项目以 DHCP 成功作为提交点；
2. 用户提交不等于凭据有效，候选配置只有验证成功后才写入 VM；
3. 新的配网意图不等于旧异步流程已经消失，必须主动屏蔽迟到事件。

这三点分别对应网络分层、事务式配置和异步状态隔离。把它们讲清楚，面试官继续追问 DHCP、Flash 凭据、强制门户、线程竞争或异常恢复时，就不会只剩下“我调用了一个 Wi-Fi 配网接口”这种表面回答。