面试时怎么讲 Wi-Fi 模组项目

先给结论

面试时不要把自己讲成：

我精通 Wi-Fi 协议栈。
我会从零实现 802.11。
我什么无线问题都能解决。

更稳的表达是：

我理解 Wi-Fi 模组在嵌入式产品里的角色，
知道 MCU 主控、Wi-Fi 模组、TCP/IP、云端协议和低功耗之间的边界，
能负责主控侧接入、状态机、数据收发、断线重连、日志诊断和测试验证。

这才是大多数 Wi-Fi 模组公司、MCU 产品公司真正需要的能力。

30 秒自我介绍版本

可以这样背：

我主要做嵌入式设备端软件，熟悉 MCU / RTOS、外设驱动、网络通信和问题定位。之前项目里做过 ESP32-S3 的 Wi-Fi 连接、WebSocket 通信、FreeRTOS 多任务、ringbuf 缓冲、LVGL UI、音频采集播放和异常恢复。

对 Wi-Fi 模组这类产品，我理解它的重点不是单纯会连网，而是要把模组稳定集成到产品里，包括主控 MCU 和模组之间的 UART/SPI 通信、联网状态机、TCP/IP 或 MQTT/HTTP 数据上传、低功耗唤醒、断线重连和量产测试。

如果进入项目，我会先看模组 datasheet、AT 指令或 SDK、联网流程、功耗模式和错误码，然后从最小联网、稳定收发、异常恢复和测试用例开始推进。

这段表达有三个优点：

1. 不吹“精通协议栈”。
2. 能贴他们的 Wi-Fi 模组产品。
3. 能把你已有 ESP32 项目经验迁移过去。

1 分钟项目贴合版本

如果面试官让你讲项目，可以这样讲：

我之前做的 ESP32-S3 项目可以理解成一个联网嵌入式终端，里面涉及 Wi-Fi 连接、TCP/WebSocket 长连接、JSON 控制消息、binary 数据传输、断线重连和运行时日志。虽然它不是专门的 Wi-Fi 模组项目，但里面很多工程问题和 Wi-Fi 模组接入是相通的。

比如主控侧要把网络模块封装成独立 service，不能让业务代码直接处理底层连接细节；网络状态要区分 Wi-Fi connected、got IP、server connected、session active；发送和接收要用 queue / ringbuf 解耦；断线后要有重连、超时、错误码和日志统计。

所以如果做贵公司的 Wi-Fi 模组，我会重点从主控接口、状态机、协议适配、低功耗和稳定性测试几个方向切入。

如何解释 FLC-WFM102 这类产品

可以这样讲：

从产品描述看，FLC-WFM102 是一个低功耗 Wi-Fi MCU 模组。它支持 2.4GHz 802.11 b/g/n、1x1 SISO、HT20，内部有 Cortex-M4F、RAM、TCP/IP 协议栈和 UART/SPI/I2C/I2S/ADC/GPIO 等接口。

这类模组既可以作为网络协处理器，通过 UART/SPI 给外部 MCU 提供联网能力，也可能在模组内部直接运行轻量业务。实际开发要先明确它在产品里是“主控”还是“联网从模块”。如果是联网从模块，主控侧重点就是 AT/私有协议、状态机、断线恢复和数据缓存；如果是 open CPU 模式，重点就是模组内部 RTOS 应用、外设驱动和网络协议栈调用。

关键词：

低功耗 Wi-Fi MCU 模组
网络协处理器
内置 TCP/IP
UART 简化接入
open CPU / AT 固件
主控与模组边界

高频问题与回答

Q1：Wi-Fi 模组和 Wi-Fi 芯片有什么区别？

短答：

Wi-Fi 芯片更偏底层器件，通常还需要外部射频、晶振、天线、驱动和协议栈适配；Wi-Fi 模组把芯片、射频匹配、天线、晶振、Flash、认证和固件能力集成起来，产品接入更快。

展开：

对嵌入式产品来说，使用 Wi-Fi 模组可以降低硬件设计和认证难度。软件侧如果模组内置 TCP/IP 或 AT 固件，主控 MCU 不需要自己实现完整网络协议栈，只要通过 UART/SPI 控制模组完成联网和数据收发。

Q2：你了解 Wi-Fi 协议栈吗？

短答：

我了解 Wi-Fi 模组产品开发需要关注的协议层次，包括 802.11 接入、DHCP、DNS、TCP/UDP、TLS、MQTT/HTTP，但我不会把自己包装成从零实现 802.11 MAC/PHY 的工程师。

展开：

我更关注工程接入层：设备从扫描 AP、认证关联、WPA 握手、获取 IP，到建立 TCP/TLS/MQTT 连接，每一层都有独立状态和错误。开发时要把 Wi-Fi connected、got IP、server connected、business online 分开处理，便于重连和定位问题。

Q3：802.11 b/g/n、HT20、1x1 SISO 怎么理解？

短答：

它说明这个模组是 2.4GHz 低功耗、低成本、稳定连接取向，不是追求高吞吐的路由器方案。

展开：

802.11b/g/n 是 Wi-Fi 标准族，2.4GHz 兼容性好但干扰多，HT20 是 20MHz 信道带宽，兼容性和抗干扰更稳，1x1 SISO 是单发单收，成本和功耗低，适合传感器、家电和普通 IoT 设备。

Q4：主控 MCU 怎么接 Wi-Fi AT 模组？

短答：

我会分层做：UART Driver、ringbuf、AT Parser、Command Dispatcher、Event Handler、Wi-Fi Manager，业务层不直接拼 AT 命令。

展开：

UART 接收用中断或 DMA 放入 ringbuf，AT Parser 区分命令响应、异步事件和网络数据。命令发送需要互斥、超时和响应匹配。Wi-Fi Manager 维护联网、IP、服务器连接、在线、重连等状态。这样比业务代码到处发 AT 命令更可维护。

Q5：Wi-Fi 断线怎么处理？

短答：

先分层定位，再按状态机恢复。

展开：

我会区分是 AP 断开、DHCP 失败、DNS 失败、TCP 断开、TLS 失败还是 MQTT keepalive 超时。恢复策略可以是 socket 重连、服务器重连、Wi-Fi 重连，严重时重启模组。重试要有退避，避免频繁重连拖垮系统。

Q6：低功耗 Wi-Fi 怎么做？

短答：

要根据业务选择 sleep 模式，不能只看最低睡眠电流。

展开：

如果是周期上报设备，可以 deep sleep，定时或外部中断唤醒，采集、联网、上传后再睡。如果需要云端实时控制，就要保持连接，使用 modem sleep、listen interval、MQTT keepalive 等策略，在功耗和实时性之间取舍。

Q7：UART 吞吐不够怎么办？

短答：

提高波特率、开启 RTS/CTS 流控、扩大 ringbuf、优化任务优先级，必要时换 SPI/SDIO。

展开：

AT 模组如果只是上传状态，UART 足够。如果传日志、OTA、大数据或音频，就要评估吞吐和流控。没有硬件流控时，模组持续下发数据可能导致主控 ringbuf overflow，进而解析错乱。

Q8：如何测试 Wi-Fi 模组稳定性？

短答：

做长时间、弱信号、断网恢复、服务器异常、低功耗唤醒和量产一致性测试。

展开：

我会记录 RSSI、重连次数、最长离线时间、发送失败次数、MQTT keepalive 超时、模组重启次数、UART overflow、唤醒到上传完成时间。这样可以判断问题在射频、网络、协议、主控接口还是业务层。

遇到不会的问题怎么接

如果被问到很底层的 802.11 MAC/PHY，比如 OFDM 细节、CSMA/CA 退避算法、射频校准参数，不要硬编。

可以这样答：

这部分更偏 Wi-Fi 芯片和射频底层，我目前没有从零实现过 802.11 MAC/PHY。我的经验更多在嵌入式产品集成层，包括 Wi-Fi 模组接入、TCP/IP 应用协议、状态机、低功耗和稳定性测试。如果项目需要深入这一层，我会结合芯片厂 SDK、协议文档和抓包工具继续补。

这个回答比乱吹更可信。

不要这样讲

避免：

我精通 Wi-Fi 协议栈。
我了解 802.11 全部细节。
Wi-Fi 断线一般就是网络不好。
低功耗就是 deep sleep。
AT 命令很简单，直接串口发就行。

替换成：

我理解 Wi-Fi 模组产品开发的分层。
我能把 Wi-Fi 接入、IP 网络、应用协议和业务在线状态拆开。
我会通过状态机、日志、错误码和测试场景定位问题。
低功耗要结合唤醒时间、重连时间和业务实时性评估。
AT 模组要处理命令响应、异步事件、数据透传和流控。

最后 30 秒总结

我对 Wi-Fi 模组的理解是：它不是单纯的无线芯片，而是嵌入式产品里的联网子系统。开发时要看清它是 MCU 模组、AT 网络协处理器，还是 host-driven 连接模组。我的优势在于主控侧集成和工程化稳定性，包括 UART/SPI 接入、状态机、TCP/IP 应用协议、断线重连、低功耗和测试诊断。对于更底层的 RF 和 802.11 MAC/PHY，我会保持边界清晰，并根据项目需要继续深入。