企业官网建设流程全解析

1. 问题定位：为什么连不上，先别急着改代码

ESP32-C3 Super Mini 这块板子最近在圈子里热度很高，体积小、价格低、自带 USB 串口，拿来跑 ESP-IDF 做联网项目非常顺手。但很多人第一次上手就会卡在同一个地方：固件烧进去了，串口日志也正常打印，可就是连不上 WiFi，esp_wifi_connect()调用之后迟迟等不到WIFI_EVENT_STA_CONNECTED，或者干脆在WIFI_EVENT_STA_DISCONNECTED里反复循环。这个现象背后可能的原因非常多，从硬件天线设计到软件配置参数，从电源供电到路由器兼容性，每一层都可能出问题。

我自己前后经手过十几块不同批次的 ESP32-C3 Super Mini，踩过的坑基本覆盖了能想到的所有情况。这篇文章就把这些经验完整梳理一遍，从最基础的硬件检查到深层的软件配置，再到抓包排查的思路，尽量让不同基础的朋友都能找到对应的解决路径。不管你是刚拿到板子的新手，还是已经调了两天没进展的老手，下面这些内容应该都能帮你省下不少时间。

需要先明确一点：ESP32-C3 Super Mini 和官方 DevKitC 之类的开发板在硬件设计上有明显差异，尤其是天线部分和电源部分。很多在官方板上跑得好好的代码，换到 Super Mini 上就出问题，根源往往不在代码本身，而在硬件特性和默认配置的匹配度上。所以排查思路要分两条线走：一条是硬件与供电，一条是软件与配置，两条线交叉验证才能快速定位。

2. 硬件层面的排查：天线、供电与引脚冲突

2.1 板载天线与射频性能的实际表现

ESP32-C3 Super Mini 用的是板载 PCB 天线，尺寸非常紧凑。这种设计的优点是省空间、成本低，缺点是增益有限，而且对周围环境极其敏感。我实测过同一块板子，放在桌面上连不上，拿起来悬空就能连上，差别就是这么明显。原因在于 PCB 天线对地平面和周围金属物体非常敏感，如果你把板子直接放在金属桌面或者靠近大面积金属物体，天线谐振频率会偏移，导致发射和接收效率急剧下降。

更隐蔽的一个问题是天线馈电点的焊接质量。Super Mini 这类小板子为了压缩成本，天线匹配网络通常只有一两个元件，焊接不良或者元件参数偏差都会导致驻波比恶化。如果你手头有频谱仪或者矢量网络分析仪，可以测一下 2.4GHz 频段的回波损耗，正常应该在 -10dB 以下。没有专业仪器的话，可以用一个简单的对比法：拿一块确认能正常联网的同型号板子，放在相同位置做对照测试，如果一块能连一块不能连，基本可以判定是天线或射频部分的硬件差异。

还有一个容易被忽略的点是 USB 线缆和接口的干扰。Super Mini 的 USB 接口离天线很近，如果用的是劣质 USB 线，屏蔽层不完整，线缆本身就会成为干扰源。我遇到过好几次，换一根带磁环的优质 USB 线，连接成功率立刻从 30% 提升到 90% 以上。这个细节在官方文档里不会写，但实际调试中非常关键。

2.2 供电不足导致的隐性故障

ESP32-C3 在 WiFi 发射瞬间的峰值电流可以到 300mA 以上，而 Super Mini 板载的 LDO 稳压芯片通常型号比较基础，输出能力有限。如果你是通过电脑 USB 口供电，而电脑 USB 口本身输出能力不足，或者 USB 线内阻偏大，就会导致发射瞬间电压跌落，芯片复位或者射频模块工作异常。这种故障的表现很有迷惑性：串口日志看起来正常，扫描 AP 也能扫到，但一连接就失败，或者连接成功后很快断开。

判断方法很简单：在 WiFi 初始化之前和连接过程中，用万用表监测 3.3V 轨的电压。如果发现连接瞬间电压跌到 3.0V 以下，基本可以确认是供电问题。解决办法有几个：一是换用带外部供电的 USB Hub，二是直接在 5V 和 GND 引脚上并联一个 100uF 以上的电解电容加一个 0.1uF 陶瓷电容，三是改用质量更好的 USB 线。我个人的习惯是在板子电源入口处直接焊一个 220uF 的钽电容，成本几毛钱，但能解决大部分偶发性连接失败。

另外要注意的是，Super Mini 上有些引脚在启动时有特殊功能，比如 GPIO9 是 BOOT 按键，GPIO8 在某些版本上连接了板载 LED。如果你在代码里把 GPIO8 配置成了其他功能，可能会影响启动模式或者引入额外电流消耗。建议在 WiFi 初始化阶段，先把所有不用的 GPIO 设置为输入且不上拉，减少不必要的功耗和干扰。

2.3 引脚冲突与启动模式陷阱

ESP32-C3 的启动模式由 GPIO2、GPIO8、GPIO9 等引脚在上电时的电平决定。Super Mini 为了缩小体积，把这些引脚直接引出来了，但没有做完善的保护电路。如果你在外围电路上不小心把这些引脚拉到了错误电平，芯片可能进入下载模式而不是正常运行模式，表现就是程序不跑或者跑起来但外设异常。

我遇到过一种情况：用户把 GPIO9 接了一个按键到地，想用作功能按键，结果每次上电芯片都进入下载模式，WiFi 自然连不上。后来把按键改到其他引脚就正常了。所以建议在设计外围电路时，先查清楚哪些引脚有启动模式功能，尽量避免在这些引脚上接会在上电时改变电平的电路。如果必须用，加一个 RC 延时或者用三极管做隔离，确保上电瞬间引脚电平正确。

还有一个细节是 Super Mini 的板载 LED。不同批次的板子 LED 连接方式不一样，有的接 GPIO8 高电平点亮，有的低电平点亮，还有的接在别的引脚上。如果你在代码里操作了 LED 引脚，而恰好这个引脚又和 WiFi 或启动模式有关，就可能引入奇怪的问题。建议在 WiFi 调试阶段先把所有 LED 操作注释掉，排除干扰。

3. 软件配置：ESP-IDF 中的关键参数与常见错误

3.1 menuconfig 里必须检查的几项配置

ESP-IDF 的配置项非常多，但和 WiFi 连接直接相关的其实就那么几个。第一个要确认的是Component config -> Wi-Fi -> WiFi Task Stack Size，默认值通常是 3584 字节，对于简单的 STA 模式够用，但如果你在 WiFi 事件回调里做了比较复杂的操作，比如打印大量日志或者调用其他阻塞函数，就可能栈溢出导致任务崩溃。我一般会把它调到 4096 或 5120，留足余量。

第二个关键项是Component config -> Wi-Fi -> WiFi RX IRAM Optimize，这个选项如果开启，会把 WiFi 接收处理放到 IRAM 里执行，提高响应速度，但会占用更多 IRAM。Super Mini 的 ESP32-C3 只有 400KB 左右的 SRAM，如果同时开了蓝牙或者其他大内存应用，可能导致内存不足。建议在纯 WiFi 应用中开启，混合应用则根据实际情况权衡。

第三个容易被忽略的是Component config -> PHY -> Calibration mode。ESP32-C3 的射频校准数据在首次上电时会写入 NVS，如果 NVS 分区损坏或者校准数据异常，WiFi 性能会严重下降。如果你怀疑校准有问题，可以在 menuconfig 里把PHY calibration设置为Full calibration，然后擦除整个 flash 重新烧录，让芯片重新做一次完整校准。这个操作我做过很多次，对于某些批次的板子确实能明显改善连接稳定性。

3.2 WiFi 初始化代码的典型错误写法

很多教程里的 WiFi 初始化代码是直接从官方示例复制过来的，但官方示例为了兼容各种场景，往往包含了很多不必要的步骤，而且有些默认参数并不适合 Super Mini。比如下面这段代码，看起来没问题，但实际上隐藏了几个坑：

wifi_init_config_t cfg = WIFI_INIT_CONFIG_DEFAULT(); ESP_ERROR_CHECK(esp_wifi_init(&cfg)); ESP_ERROR_CHECK(esp_wifi_set_mode(WIFI_MODE_STA)); wifi_config_t wifi_config = { .sta = { .ssid = "MySSID", .password = "MyPassword", }, }; ESP_ERROR_CHECK(esp_wifi_set_config(WIFI_IF_STA, &wifi_config)); ESP_ERROR_CHECK(esp_wifi_start()); ESP_ERROR_CHECK(esp_wifi_connect());

第一个坑是WIFI_INIT_CONFIG_DEFAULT()里的默认 NVS 配置。如果你的项目里没有初始化 NVS，或者 NVS 分区表配置不对，WiFi 驱动在保存校准数据时会失败，导致连接异常。正确的做法是在app_main最开始就调用nvs_flash_init()，并检查返回值，如果返回ESP_ERR_NVS_NO_FREE_PAGES或ESP_ERR_NVS_NEW_VERSION_FOUND，就擦除 NVS 重新初始化。

第二个坑是esp_wifi_connect()的调用时机。有些代码在esp_wifi_start()之后立刻调用esp_wifi_connect()，但此时 WiFi 驱动可能还没完全就绪，导致连接请求被丢弃。更稳妥的做法是在事件回调里收到WIFI_EVENT_STA_START事件后再调用esp_wifi_connect()。这个细节在官方文档里有提到，但很多快速上手教程都省略了。

第三个坑是 SSID 和密码的格式。wifi_config_t里的ssid和password是固定长度数组，不是字符串指针。如果你用strcpy或者直接赋值字符串字面量，可能不会报错，但实际内容可能不对。正确的做法是用memcpy并确保长度不超过 32 字节（SSID）和 64 字节（密码）。另外，如果 SSID 或密码里包含特殊字符，要注意转义和编码问题。

3.3 事件循环与重连逻辑的设计

WiFi 连接是一个异步过程，必须通过事件回调来处理各种状态变化。很多初学者只注册了事件处理函数，但没有正确处理WIFI_EVENT_STA_DISCONNECTED事件，导致断开后不会自动重连。下面是一个我常用的重连逻辑框架：

static void wifi_event_handler(void* arg, esp_event_base_t event_base, int32_t event_id, void* event_data) { if (event_base == WIFI_EVENT && event_id == WIFI_EVENT_STA_START) { esp_wifi_connect(); } else if (event_base == WIFI_EVENT && event_id == WIFI_EVENT_STA_DISCONNECTED) { wifi_event_sta_disconnected_t* disconnected = (wifi_event_sta_disconnected_t*) event_data; ESP_LOGW(TAG, "Disconnected, reason: %d", disconnected->reason); vTaskDelay(pdMS_TO_TICKS(2000)); esp_wifi_connect(); } else if (event_base == IP_EVENT && event_id == IP_EVENT_STA_GOT_IP) { ip_event_got_ip_t* got_ip = (ip_event_got_ip_t*) event_data; ESP_LOGI(TAG, "Got IP: " IPSTR, IP2STR(&got_ip->ip_info.ip)); } }

这段代码的关键点在于：断开后先延时 2 秒再重连，避免过于频繁的重连请求导致路由器拒绝服务。另外，disconnected->reason这个字段非常重要，它直接告诉你断开的原因。常见的 reason code 有 201（NO_AP_FOUND）、202（AUTH_FAIL）、203（ASSOC_FAIL）、205（CONNECTION_FAIL）等。根据不同的 reason code，可以判断是密码错误、信号太弱还是路由器兼容性问题。

我建议在调试阶段把 reason code 打印出来，然后对照 ESP-IDF 的esp_wifi_types.h头文件里的wifi_err_reason_t枚举来排查。比如如果一直报 201，说明根本没扫到目标 AP，问题在射频或天线；如果报 202，说明密码或加密方式不对；如果报 205，可能是路由器设置了 MAC 地址过滤或者连接数已满。

4. 路由器兼容性与射频环境排查

4.1 2.4GHz 频段的信道与带宽设置

ESP32-C3 只支持 2.4GHz 频段，不支持 5GHz。如果你家的路由器是双频合一，而且默认把 2.4G 和 5G 用了同一个 SSID，那 ESP32-C3 在扫描时可能会看到两个同名 AP，连接时可能选到 5G 那个，自然连不上。解决办法是在路由器设置里把 2.4G 和 5G 的 SSID 分开，明确让 ESP32-C3 连 2.4G 的那个。

另外，2.4GHz 频段的信道选择也很重要。国内常用的信道是 1 到 13，但有些路由器默认只开 1、6、11 这三个。ESP32-C3 支持全信道扫描，但如果路由器用了 12 或 13 信道，而你的代码里设置了scan_method为快速扫描或者指定了信道列表，就可能扫不到。建议在调试阶段把扫描配置设为全信道扫描，确认能扫到目标 AP 后再优化。

带宽方面，ESP32-C3 支持 20MHz 和 40MHz，但 40MHz 在拥挤的 2.4G 频段反而容易受干扰。我一般建议在 menuconfig 里把WiFi bandwidth设为 20MHz，牺牲一点理论速率换取更好的稳定性。实测下来，20MHz 模式下连接成功率和丢包率都明显优于 40MHz。

4.2 路由器安全模式与加密方式

不同品牌的路由器对 WiFi 安全模式的实现有差异。ESP32-C3 支持 WPA2-PSK、WPA3-SAE 等模式，但有些老路由器用的 WPA-TKIP 或者混合模式，ESP32-C3 可能兼容性不好。如果你遇到密码正确但一直认证失败的情况，可以尝试把路由器的安全模式改成纯 WPA2-PSK（AES），关掉 TKIP 和 WPA3 混合模式。

还有一个坑是路由器的隐藏 SSID 功能。如果 AP 设置了隐藏 SSID，ESP32-C3 需要主动发送探测请求才能连接，而默认的esp_wifi_connect()可能不会触发主动扫描。这种情况下需要在wifi_config_t里设置bssid_set为 true，并指定目标 AP 的 BSSID。或者先调用esp_wifi_scan_start()做一次主动扫描，拿到 BSSID 后再连接。

MAC 地址过滤也是常见问题。有些路由器开启了白名单模式，只允许已登记的 MAC 地址连接。ESP32-C3 的 MAC 地址是芯片出厂时烧录的，可以在代码里用esp_wifi_get_mac()读取，然后添加到路由器白名单里。如果你不想改路由器设置，也可以在代码里用esp_wifi_set_mac()修改 MAC 地址，但要注意不要和网络中其他设备冲突。

4.3 射频干扰与共存问题

2.4GHz 频段非常拥挤，除了 WiFi 还有蓝牙、无线鼠标、微波炉等设备。如果你在调试时发现连接时好时坏，可以尝试换个位置或者换个时间段测试。我遇到过在办公室环境下，下午两点到四点之间连接成功率明显下降，后来发现是隔壁会议室的无线投屏设备在大量占用信道。

ESP32-C3 支持 WiFi 和蓝牙共存，但共存模式下两者会分时复用射频资源，可能导致 WiFi 吞吐量下降和延迟增加。如果你的项目不需要蓝牙，建议在 menuconfig 里把蓝牙关掉，减少射频竞争。如果必须同时使用，可以在Component config -> Bluetooth -> Bluedroid Options里调整共存优先级，把 WiFi 设为高优先级。

另外，Super Mini 板子上的 USB 接口在数据传输时也会产生射频噪声，尤其是 USB 2.0 高速模式。如果你在 WiFi 连接的同时通过 USB 串口大量打印日志，可能会干扰 WiFi 接收。建议在 WiFi 连接阶段减少串口日志输出，或者把日志等级调高，只打印错误信息。

5. 抓包与日志分析：用数据说话

5.1 串口日志的关键字段解读

ESP-IDF 的 WiFi 驱动日志非常详细，但默认日志等级可能不够。建议在 menuconfig 里把Component config -> Log output -> Default log verbosity设为Debug，然后在代码里用esp_log_level_set("wifi", ESP_LOG_DEBUG)单独提高 WiFi 组件的日志等级。这样可以看到扫描结果、认证过程、关联过程等详细信息。

日志里几个关键字段需要重点关注：scan开头的行会列出扫描到的所有 AP，包括 SSID、BSSID、信道、RSSI、加密方式。如果目标 AP 不在列表里，说明射频或扫描配置有问题。auth开头的行会显示认证过程，如果卡在auth阶段，通常是密码或加密方式不匹配。assoc开头的行显示关联过程，如果关联失败，可能是路由器连接数已满或者信号太弱。

RSSI 值也很重要。一般来说，RSSI 高于 -60dBm 算信号良好，-60 到 -70dBm 算一般，低于 -80dBm 就很容易断连。如果你看到目标 AP 的 RSSI 只有 -85dBm，那基本可以判定是信号太弱，需要调整板子位置或者加外置天线。Super Mini 没有外置天线接口，但可以自己飞线焊一个 IPEX 座子，或者把板子放在离路由器更近的地方。

5.2 使用 Wireshark 做空口抓包

如果串口日志看不出问题，就需要上抓包工具了。最常用的方案是用一块支持监听模式的网卡，配合 Wireshark 抓取空口数据包。在 Linux 下可以用airmon-ng把网卡切到监听模式，然后wireshark选择对应接口开始抓包。Windows 下可以用Npcap加Wireshark，但需要网卡驱动支持监听模式。

抓包时先过滤目标 AP 的 BSSID，然后看 ESP32-C3 发出的认证请求和路由器的响应。如果看到 ESP32-C3 发了认证请求但路由器没有响应，说明路由器可能屏蔽了该 MAC 地址或者信号太弱。如果路由器回了认证响应但 ESP32-C3 没有继续关联，可能是 ESP32-C3 端的认证算法不匹配。如果关联成功但 DHCP 失败，那就是 IP 层的问题，需要检查路由器的 DHCP 池是否已满。

空口抓包的门槛稍高，但它是定位射频层问题的终极手段。我建议在排查超过半天还没进展时，就果断上抓包，往往几分钟就能找到根因。没有专业网卡的话，也可以用另一块 ESP32 开发板烧录嗅探固件来做简易抓包，虽然功能有限，但看认证和关联过程足够了。

5.3 常见错误码速查与对应处理

下面这张表是我根据实际调试经验整理的常见错误码和处理方法，可以直接对照排查：

这张表建议保存下来，下次遇到问题先查错误码，能省很多时间。需要注意的是，同一个错误码可能有多种原因，比如 202 既可能是密码错误，也可能是路由器开启了 MAC 过滤。所以还是要结合日志和抓包综合判断。

6. 实操案例：从零搭建一个稳定的 WiFi 连接

6.1 项目初始化与分区表配置

下面用一个完整的例子来演示如何从零搭建一个稳定的 WiFi 连接。首先创建项目：

idf.py create-project wifi_sta_demo cd wifi_sta_demo idf.py set-target esp32c3

然后配置分区表。Super Mini 的 flash 通常是 4MB，默认分区表可能不够用。在项目根目录创建partitions.csv：

# Name, Type, SubType, Offset, Size, Flags nvs, data, nvs, 0x9000, 0x6000, phy_init, data, phy, 0xf000, 0x1000, factory, app, factory, 0x10000, 0x300000,

然后在 menuconfig 里选择自定义分区表：Partition Table -> Custom partition table CSV，填入partitions.csv。这样 NVS 有 24KB，足够保存 WiFi 校准数据和用户配置。

6.2 完整的 WiFi 初始化与重连代码

下面是完整的main.c，包含了 NVS 初始化、WiFi 初始化、事件处理和重连逻辑：

#include <string.h> #include "freertos/FreeRTOS.h" #include "freertos/task.h" #include "freertos/event_groups.h" #include "esp_system.h" #include "esp_wifi.h" #include "esp_event.h" #include "esp_log.h" #include "nvs_flash.h" #define WIFI_SSID "YourSSID" #define WIFI_PASS "YourPassword" #define MAX_RETRY 10 static const char *TAG = "wifi_sta"; static EventGroupHandle_t s_wifi_event_group; static int s_retry_num = 0; #define WIFI_CONNECTED_BIT BIT0 #define WIFI_FAIL_BIT BIT1 static void event_handler(void* arg, esp_event_base_t event_base, int32_t event_id, void* event_data) { if (event_base == WIFI_EVENT && event_id == WIFI_EVENT_STA_START) { esp_wifi_connect(); } else if (event_base == WIFI_EVENT && event_id == WIFI_EVENT_STA_DISCONNECTED) { wifi_event_sta_disconnected_t* disc = (wifi_event_sta_disconnected_t*) event_data; ESP_LOGW(TAG, "Disconnected, reason=%d", disc->reason); if (s_retry_num < MAX_RETRY) { esp_wifi_connect(); s_retry_num++; ESP_LOGI(TAG, "Retry to connect (%d/%d)", s_retry_num, MAX_RETRY); } else { xEventGroupSetBits(s_wifi_event_group, WIFI_FAIL_BIT); } } else if (event_base == IP_EVENT && event_id == IP_EVENT_STA_GOT_IP) { ip_event_got_ip_t* event = (ip_event_got_ip_t*) event_data; ESP_LOGI(TAG, "Got IP: " IPSTR, IP2STR(&event->ip_info.ip)); s_retry_num = 0; xEventGroupSetBits(s_wifi_event_group, WIFI_CONNECTED_BIT); } } void wifi_init_sta(void) { s_wifi_event_group = xEventGroupCreate(); ESP_ERROR_CHECK(esp_netif_init()); ESP_ERROR_CHECK(esp_event_loop_create_default()); esp_netif_create_default_wifi_sta(); wifi_init_config_t cfg = WIFI_INIT_CONFIG_DEFAULT(); ESP_ERROR_CHECK(esp_wifi_init(&cfg)); esp_event_handler_instance_t instance_any_id; esp_event_handler_instance_t instance_got_ip; ESP_ERROR_CHECK(esp_event_handler_instance_register(WIFI_EVENT, ESP_EVENT_ANY_ID, &event_handler, NULL, &instance_any_id)); ESP_ERROR_CHECK(esp_event_handler_instance_register(IP_EVENT, IP_EVENT_STA_GOT_IP, &event_handler, NULL, &instance_got_ip)); wifi_config_t wifi_config = { .sta = { .ssid = WIFI_SSID, .password = WIFI_PASS, .threshold.authmode = WIFI_AUTH_WPA2_PSK, .sae_pwe_h2e = WPA3_SAE_PWE_BOTH, }, }; ESP_ERROR_CHECK(esp_wifi_set_mode(WIFI_MODE_STA)); ESP_ERROR_CHECK(esp_wifi_set_config(WIFI_IF_STA, &wifi_config)); ESP_ERROR_CHECK(esp_wifi_start()); ESP_LOGI(TAG, "wifi_init_sta finished."); EventBits_t bits = xEventGroupWaitBits(s_wifi_event_group, WIFI_CONNECTED_BIT | WIFI_FAIL_BIT, pdFALSE, pdFALSE, portMAX_DELAY); if (bits & WIFI_CONNECTED_BIT) { ESP_LOGI(TAG, "Connected to AP SSID:%s", WIFI_SSID); } else if (bits & WIFI_FAIL_BIT) { ESP_LOGI(TAG, "Failed to connect to SSID:%s", WIFI_SSID); } } void app_main(void) { esp_err_t ret = nvs_flash_init(); if (ret == ESP_ERR_NVS_NO_FREE_PAGES || ret == ESP_ERR_NVS_NEW_VERSION_FOUND) { ESP_ERROR_CHECK(nvs_flash_erase()); ret = nvs_flash_init(); } ESP_ERROR_CHECK(ret); wifi_init_sta(); }

这段代码有几个关键点：一是 NVS 初始化时处理了两种常见错误，二是事件回调里根据 reason code 打印日志，三是重连次数限制为 10 次，避免无限重连。另外threshold.authmode设为WIFI_AUTH_WPA2_PSK，如果你的路由器是 WPA3，可以改成WIFI_AUTH_WPA3_PSK或者WIFI_AUTH_WPA2_WPA3_PSK。

6.3 编译烧录与串口监控

编译和烧录命令如下：

idf.py build idf.py -p /dev/ttyUSB0 flash monitor

Windows 下端口号可能是COM3之类的，用idf.py -p COM3 flash monitor。烧录时如果遇到Failed to connect，按住 BOOT 键再按 RESET 键进入下载模式。烧录完成后串口会打印日志，正常的话应该能看到扫描、认证、关联、获取 IP 的完整过程。

如果连接失败，先看 reason code，然后对照前面的表格排查。我建议在调试阶段把esp_log_level_set("wifi", ESP_LOG_DEBUG)加上，这样能看到更详细的驱动日志。另外可以在menuconfig里把Component config -> Wi-Fi -> WiFi debug log level设为Verbose，但注意日志量会很大，可能影响实时性。

7. 进阶技巧与长期稳定性优化

7.1 降低功耗与提升连接速度的平衡

如果你的项目是电池供电，需要在连接速度和功耗之间做权衡。ESP32-C3 支持 Modem-sleep 和 Light-sleep 模式，可以在 WiFi 连接空闲时降低功耗。在 menuconfig 里开启Component config -> Power Management -> Support light sleep，然后在代码里调用esp_wifi_set_ps(WIFI_PS_MIN_MODEM)或WIFI_PS_MAX_MODEM。但要注意，省电模式会增加连接延迟，如果对实时性要求高，建议用WIFI_PS_NONE。

另外，WiFi 扫描阶段非常耗电，如果不需要每次上电都扫描，可以在 NVS 里保存上次连接的 BSSID 和信道，下次直接连接，跳过扫描过程。这样既能加快连接速度，又能降低功耗。实现方法是在获取 IP 后调用esp_wifi_get_ap_info()拿到 BSSID 和信道，保存到 NVS，下次初始化时设置bssid_set和channel。

7.2 长时间运行的内存与稳定性监控

WiFi 驱动在长时间运行后可能会出现内存碎片或者任务栈溢出。建议在项目里加一个定时任务，每隔一段时间打印esp_get_free_heap_size()和uxTaskGetStackHighWaterMark()，监控内存和栈的使用情况。如果发现空闲内存持续下降，可能存在内存泄漏，需要检查事件回调里是否有未释放的资源。

另外，ESP-IDF 提供了esp_wifi_statis_dump()函数，可以打印 WiFi 统计信息，包括发送接收包数、重传次数、错误计数等。定期调用这个函数可以帮助发现潜在的射频问题。如果重传次数异常高，说明信号质量差或者干扰严重，需要调整天线或信道。

7.3 固件升级与配置持久化

产品化项目中，固件升级和配置持久化是必须考虑的。ESP-IDF 支持 OTA 升级，可以通过 WiFi 下载新固件并写入 flash。OTA 过程中 WiFi 连接必须稳定，否则升级失败可能导致设备变砖。建议在 OTA 前先检查 RSSI 和可用内存，确保条件满足再开始升级。

配置持久化方面，除了 WiFi 的 SSID 和密码，可能还需要保存服务器地址、设备 ID 等信息。建议统一用 NVS 存储，并给每个配置项分配独立的命名空间和键名，避免冲突。NVS 的读写次数有限，不要频繁写入，可以在配置变更时批量写入，或者用延时写入策略减少擦写次数。

8. 我踩过的那些坑与最后的小技巧

回头看这几年调试 ESP32-C3 Super Mini 的经历，有几个坑印象特别深。一个是天线附近放了锂电池，导致 WiFi 信号直接被屏蔽，排查了一整天才发现。另一个是用了某品牌的 USB 快充头，输出电压波动大，WiFi 连接时好时坏，换回普通 5V 电源就正常了。还有一个是路由器开启了 MU-MIMO 和波束成形，ESP32-C3 兼容性不好，关掉这两个功能后连接立刻稳定。

最后分享一个小技巧：如果你手头没有专业仪器，可以用手机上的 WiFi 分析 App 查看周围信道占用情况，选一个最空闲的信道给路由器用。另外，在代码里加一个看门狗任务，如果 WiFi 超过一定时间没连上就主动重启，比无限重连更可靠。这些经验都是实际调试中积累的，希望能帮你少走弯路。