玩嵌入式这几年，凡是做电池供电的设备，功耗永远绕不开。ESP32性能强、外设多、Wi-Fi/蓝牙都有，典型的“什么都能干”，但也正因为什么都能干，待机电流动不动几十毫安，直接把电池干穿。很多朋友一说到低功耗，第一反应就是Deep-sleep，睡死过去，电流能降到微安级，然后通过定时器或者GPIO把设备叫醒。但问题是，你要是还需要Wi-Fi保持在线、让服务器随时能下发指令，Deep-sleep根本做不到——每次唤醒都要重新连接路由器、重新走TCP/TLS握手，又慢又费电，后台一旦需要主动找设备，设备还经常不在线。
所以这次我想聊的是Light-sleep，而且专门讲“Wi-Fi保持连接”场景下的Light-sleep。简单说，它能让CPU停下来，RAM数据不丢，Wi-Fi模块也不会彻底断开，路由器那边以为你还在线，实际芯片已经进入低功耗状态。实测下来，在保留Wi-Fi连接的前提下，整机电流能从几十毫安压到1mA上下，对电池供电、又需要实时在线监控设备来说，这个方案基本是唯一解。
这篇内容会从ESP32的功耗模式区别、Light-sleep的底层原理、完整代码解析，到我实测的功耗数据和踩过的坑，一次讲透。适合已经在用ESP32做项目、想把待机功耗压下来，或者正在纠结“要在线还是要省电”的朋友。
1. 先搞清楚ESP32的功耗模式，才知道电都花在了哪里
1.1 四档功耗模式逐个对比
ESP32官方手册里，运行状态下的功耗模式分这么几档：Active（活动）、Modem-sleep（调制解调器睡眠）、Light-sleep（轻度睡眠）、Deep-sleep（深度睡眠）。很多资料把Modem-sleep和Light-sleep混着讲，其实这俩有本质区别。
拿手机打比方，Active就是屏幕亮着、你正在刷视频，CPU全速跑、射频全开；Modem-sleep相当于你把网络关了但手机还在亮屏刷本地照片，CPU继续工作，只是Wi-Fi射频间歇性休眠；Light-sleep就是手机锁屏了，屏幕熄灭、大部分处理器停下，但内存数据还在，后台还能定时收一下消息通知；Deep-sleep则接近关机，只保留极少数电路维持唤醒能力。
对应到ESP32上，四档模式的具体状态：
| 模式 | CPU | 高频时钟 | SRAM | RTC内存 | Wi-Fi/BT | 唤醒方式 | 典型电流 |
|---|---|---|---|---|---|---|---|
| Active | 运行 | 开启 | 保持 | 保持 | 全速工作 | - | 80-240mA |
| Modem-sleep | 运行 | 开启 | 保持 | 保持 | 射频间歇关闭 | - | 20-40mA |
| Light-sleep | 暂停 | 关闭 | 保持 | 保持 | 可保持连接（Beacon监听） | 定时器/GPIO/UART等 | 0.8-2mA |
| Deep-sleep | 断电 | 关闭 | 断电 | 保持 | 关闭 | 定时器/GPIO/触摸 | 10-150uA |
这里要特别说明，表格里的电流是参考范围，实际上跟模组型号、供电方案、工作电压关系很大。官方模组和第三方模组有差异，同一个模组在不同主频下面电流差别也不小。但趋势是明确的：Light-sleep把功耗拉低了两个数量级，同时保留了Deep-sleep没有的“快速恢复”和“Wi-Fi在线”能力。
1.2 为什么做Wi-Fi设备，首选Light-sleep而不是Deep-sleep
很多刚接触低功耗的朋友会问：既然Deep-sleep电流最低，为什么不用Deep-sleep？问题在于，Deep-sleep一进去，CPU断电、大部分内存断电，Wi-Fi和蓝牙也全部关闭。你要重新工作，必须经历完整的复位、重新初始化、重新连接Wi-Fi、重新建立TCP/TLS连接。
这一套流程走下来，快则几百毫秒，慢则两三秒。更关键的是，设备在睡眠期间网络是完全离线的，服务器推送的消息、App下发的指令，全部收不到。对于需要“实时在线”的物联网设备，比如远程控制开关、环境监测站、设备状态上报器，Deep-sleep意味着你永远无法第一时间响应远端的请求。
Light-sleep就不一样。它保留了SRAM内容，唤醒后代码接着往下跑，很多外设状态也能维持；Wi-Fi保持关联状态，路由器知道设备在线，数据包到了会先在AP侧缓存，等设备醒来收Beacon时一并取走。整体唤醒时间在毫秒级，这对应用层来说几乎是无感的。
所以我的结论很明确：如果你的项目对实时在线有要求，同时又要电池供电，Light-sleep是第一选择；如果项目可以接受几分钟甚至更长时间上报一次数据，那Deep-sleep更合适。两者不是替代关系，是根据业务场景选型的问题。
2. Light-sleep为什么能让Wi-Fi不掉线：Beacon监听机制拆解
2.1 路由器是怎么“叫醒”设备的
Light-sleep下Wi-Fi还能保持在线，靠的是路由器的一个机制：Beacon帧。
Wi-Fi路由器每隔一段时间（通常是100ms，也就是10Hz）会广播一个Beacon帧，你可以理解成路由器在喊“我在这里，有设备在线的举手”。在有设备休眠时，路由器会把发给这个设备的数据暂时缓存起来，然后在Beacon帧的TIM（Traffic Indication Map）字段里标注“你有数据待取”。支持省电模式的设备在休眠期间并不会一直关闭射频，而是会在Beacon周期到来时定时醒来，听一下TIM：如果发现路由器有缓存的数据，就主动发送PS-Poll帧把数据取回来；没有数据，就继续睡。
DTIM（Delivery Traffic Indication Message）是TIM的一种特殊形态，每隔若干个Beacon出现一次，用于广播和组播数据的投递通知。DTIM周期默认情况下一般是3，意味着路由器每3个Beacon周期才会去通知广播数据的传送。
这部分机制背后就是Wi-Fi协议里的PSM（Power Save Mode），ESP32在Light-sleep状态下做的，本质上就是把这种“周期性醒来听Beacon”的机制用到了极致。射频模块不会完全关闭，而是掐准Beacon时刻短暂唤醒，收完包立刻又睡过去，整体平均电流就被压下去了。
2.2 动态调频和自动睡眠是如何配合的
ESP-IDF里跟Light-sleep关系最密切的是电源管理服务（Power Management）。它做的事情不只睡眠本身，还包括动态调频（DFS，Dynamic Frequency Scaling）。
系统默认情况下CPU跑在160MHz甚至240MHz，但很多场景根本不需要这么高的频率。电源管理服务会根据当前任务负载自动降频：有活干就跑到设定的最高频率，空闲了就把频率降到最低档，再空闲就直接进入Light-sleep。这个过程对应用层是透明的。
关键来了，要让自动Light-sleep生效，必须在初始化时告诉电源管理服务三件事：最高允许频率、最低允许频率、是否允许Light-sleep。这里有一个常见的坑：如果你在代码里通过esp_pm_lock_acquire持有某个频率锁（比如Wi-Fi或蓝牙驱动的锁，或者你自己为了跑某个高精度外设拿的锁），空闲时系统自动睡眠就会失效，只能降频，不能入睡。
2.3 唤醒源怎么选：定时器、GPIO、还是UART
Light-sleep虽然可以自动进入、定时醒来，但你得先设定好唤醒源。ESP32支持的唤醒源不少：定时器、GPIO（包括RTC GPIO和普通GPIO的Light-sleep唤醒，芯片版本不同有差异）、UART、触摸传感器、ADC等。
定时器唤醒适合周期性场景。比如环境监测节点每30秒醒来采样一次温湿度、上报服务器，然后继续睡，代码上就是esp_sleep_enable_timer_wakeup(30 * 1000000)，单位是微秒。GPIO唤醒适合事件驱动场景，比如门磁传感器、人体感应、按键触发，有事件了才需要唤醒系统。UART唤醒适合本地调试或需要串口命令唤醒的场景。
我的实际经验是，大多数产品会把定时器唤醒和GPIO唤醒组合使用：平时定时上报心跳，同时留一个GPIO作为外部事件的即时唤醒入口。比如智能开关，既需要每秒（或每几秒）上报状态，又需要物理按键能立刻唤醒处理。两者同时配置，互不冲突。
3. 实战：基于ESP-IDF的Light-sleep低功耗工程（附源码解析）
3.1 开发环境与工程准备
我这边用的是ESP-IDF v5.x版本，配合VS Code的ESP-IDF插件。这套组合在配置工程、烧录、查看日志方面都比较顺手，而且v5.x的电源管理API已经相当稳定。
创建工程时，直接选择esp-idf-template或者手动cmake新建都行。关键在menuconfig里的几个配置项：
- Component config → Wi-Fi → WiFi modem sleep：选择
Modem Sleep开启 - Component config → Power Management：勾选
Enable power management，这个不开，后面的API直接返回错误 - Component config → FreeRTOS → Tickless idle：勾选支持Tickless模式，这样FreeRTOS的空闲任务才能触发进入Light-sleep
还需要注意芯片型号对应的头文件。ESP32、ESP32-S3、ESP32-C3的电源管理配置结构体名字不一样，ESP32用的是esp_pm_config_esp32_t，ESP32-S3用的是esp_pm_config_esp32s3_t，别搞混了，否则编译直接报类型不匹配。
3.2 代码整体架构与初始化流程
先放一个最小可运行的完整工程结构，主文件里包含了Wi-Fi连接和Light-sleep的完整初始化流程，代码基于ESP-IDF v5.2：
#include <stdio.h> #include "freertos/FreeRTOS.h" #include "freertos/task.h" #include "esp_log.h" #include "esp_wifi.h" #include "esp_event.h" #include "esp_pm.h" #include "esp_sleep.h" #include "esp_timer.h" #include "nvs_flash.h" #include "driver/gpio.h" #define WIFI_SSID "your_ssid" #define WIFI_PASS "your_password" #define SAMPLE_TASK_PERIOD_MS 10000 static const char *TAG = "light_sleep_demo"; // GPIO唤醒，这里用GPIO0（BOOT按键）做演示 #define WAKEUP_GPIO GPIO_NUM_0 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) { ESP_LOGW(TAG, "Wi-Fi disconnected, trying to reconnect..."); esp_wifi_connect(); } else if (event_base == IP_EVENT && event_id == IP_EVENT_STA_GOT_IP) { ESP_LOGI(TAG, "Got IP address"); } } static void wifi_init(void) { esp_netif_init(); esp_event_loop_create_default(); esp_netif_create_default_wifi_sta(); wifi_init_config_t cfg = WIFI_INIT_CONFIG_DEFAULT(); esp_wifi_init(&cfg); esp_event_handler_register(WIFI_EVENT, ESP_EVENT_ANY_ID, &wifi_event_handler, NULL); esp_event_handler_register(IP_EVENT, IP_EVENT_STA_GOT_IP, &wifi_event_handler, NULL); wifi_config_t wifi_config = { .sta = { .ssid = WIFI_SSID, .password = WIFI_PASS, .threshold.authmode = WIFI_AUTH_WPA2_PSK, }, }; esp_wifi_set_mode(WIFI_MODE_STA); esp_wifi_set_config(WIFI_IF_STA, &wifi_config); esp_wifi_start(); // 这是让Wi-Fi在睡眠期间保持连接的核心选项 esp_wifi_set_ps(WIFI_PS_MIN_MODEM); } static void init_power_management(void) { #if CONFIG_IDF_TARGET_ESP32 esp_pm_config_esp32_t pm_config = { .max_freq_mhz = 160, .min_freq_mhz = 80, .light_sleep_enable = true, }; #elif CONFIG_IDF_TARGET_ESP32S3 esp_pm_config_esp32s3_t pm_config = { .max_freq_mhz = 160, .min_freq_mhz = 80, .light_sleep_enable = true, }; #elif CONFIG_IDF_TARGET_ESP32C3 esp_pm_config_esp32c3_t pm_config = { .max_freq_mhz = 160, .min_freq_mhz = 80, .light_sleep_enable = true, }; #endif esp_err_t ret = esp_pm_configure(&pm_config); if (ret != ESP_OK) { ESP_LOGE(TAG, "Power management config failed: %s", esp_err_to_name(ret)); } else { ESP_LOGI(TAG, "Power management enabled, light-sleep is allowed"); } } static void init_wakeup_sources(void) { // 定时器唤醒：每10秒醒一次 esp_sleep_enable_timer_wakeup(10 * 1000000ULL); // GPIO唤醒：配置GPIO0低电平唤醒 gpio_config_t io_conf = { .pin_bit_mask = (1ULL << WAKEUP_GPIO), .mode = GPIO_MODE_INPUT, .intr_type = GPIO_INTR_LOW_LEVEL, }; gpio_config(&io_conf); gpio_wakeup_enable(WAKEUP_GPIO, GPIO_INTR_LOW_LEVEL); esp_sleep_enable_gpio_wakeup(); ESP_LOGI(TAG, "Wakeup sources: timer(10s) + GPIO0(low level)"); } void app_main(void) { ESP_ERROR_CHECK(nvs_flash_init()); init_power_management(); wifi_init(); init_wakeup_sources(); while (1) { ESP_LOGI(TAG, "Main task running..."); vTaskDelay(pdMS_TO_TICKS(SAMPLE_TASK_PERIOD_MS)); // 主动让出CPU，触发电源管理在空闲时进入Light-sleep // 也可以直接调用 esp_pm_light_sleep_start() 强制睡眠 } }这段代码在开发板上跑起来，连接Wi-Fi之后，每次空闲都会自动进入Light-sleep，10秒定时器到点自动醒来，GPIO0被拉低也会立刻唤醒。
3.3 核心代码逐段拆解
这个工程里真正决定Light-sleep能不能生效的，就是esp_wifi_set_ps(WIFI_PS_MIN_MODEM)和esp_pm_configure这两处配置，其他都是外围配套。
先看esp_wifi_set_ps。Wi-Fi省电模式有三个可选项：WIFI_PS_NONE表示Wi-Fi射频一直全速工作，不省电；WIFI_PS_MIN_MODEM表示开启Modem Sleep，Wi-Fi在空闲时关闭射频，仅在Beacon周期醒来；WIFI_PS_MAX_MODEM是最大省电模式，Beacon监听间隔会被拉得更长，但同时唤醒延迟也更大，不太适合需要及时收包的场景。
很多教程里只写了esp_wifi_set_ps，没写电源管理配置，结果发现OpenOCD调试器一挂上，功耗还是居高不下。原因在于调试器本身会阻止睡眠。所以在做功耗测试时，务必拔掉调试器、断开串口连接，只保留供电和电流表。
再看esp_pm_configure。注意一个细节：.min_freq_mhz = 80。这个最低频率不是越低越好，因为Wi-Fi驱动在收发数据时需要一定CPU频率，如果频率锁定的最低值太低，反而会导致Wi-Fi任务跑不完、频繁报错。实测下来80MHz是比较稳的底限，再低容易出一些莫名其妙的问题。
light_sleep_enable = true是总开关。开了它之后，FreeRTOS的空闲任务会在系统无事可做时自动进入Light-sleep，不需要手动调用。这是最简单、最不容易出错的姿势。
另外还有主动进入的方式。如果你的业务逻辑比较特殊，想让系统在特定时刻强制睡一下，可以在合适的时机调用：
esp_pm_light_sleep_start();esp_pm_light_sleep_start()会立刻让CPU进入睡眠，直到唤醒源触发。这种方式适合你已经明确“接下来10秒不需要干活”的场景，比如采集完数据、上报完，直接睡过去。
3.4 唤醒之后怎么处理事件
每次Light-sleep唤醒，程序并不会重启，而是继续在进入睡眠之前的位置往下执行。所以你需要在每次循环或事件处理里判断一下：这次醒来是因为定时器，还是GPIO，还是其他原因。
判断唤醒来源的API：
esp_sleep_wakeup_cause_t cause = esp_sleep_get_wakeup_cause(); switch (cause) { case ESP_SLEEP_WAKEUP_TIMER: ESP_LOGI(TAG, "Woke up by timer"); // 执行定时上报任务 break; case ESP_SLEEP_WAKEUP_GPIO: ESP_LOGI(TAG, "Woke up by GPIO"); // 执行按键/事件处理任务 break; case ESP_SLEEP_WAKEUP_UART: ESP_LOGI(TAG, "Woke up by UART"); break; default: ESP_LOGW(TAG, "Wakeup cause: %d", cause); break; }注意，如果是GPIO唤醒，还要用esp_sleep_get_gpio_wakeup_status()去确认具体是哪个GPIO触发的，尤其在多个GPIO同时配置为唤醒源时，不查状态根本不知道谁醒了：
uint64_t gpio_mask = esp_sleep_get_gpio_wakeup_status(); if (gpio_mask & (1ULL << GPIO_NUM_0)) { ESP_LOGI(TAG, "GPIO0 triggered wakeup"); }4. 实测数据：连接保持下Light-sleep的功耗长什么样
4.1 我的测试环境与测量方法
既然是讲低功耗，没有实测数据等于白讲。我用的是ESP32-DevKitC V4开发板，把板载的AMS1117稳压芯片摘掉，直接3.7V锂聚合物电池通过一个低静态电流的DCDC降压到3.3V给模组供电。测量工具是一块精度到0.1uA的台式万用表，串接在电池正极和DCDC输入端之间。
这里有个很容易被忽略的点：开发板上的USB转串口芯片（比如CP2102）在不工作的时候也会吃掉几毫安的电流。如果你直接拿一块开发板测功耗，无论软件怎么优化，电流都会卡在几毫安下不去。我一开始用完整开发板测，Light-sleep时整机电流稳定在4.2mA，后来把板载串口芯片的供电断开，电流直接掉到1mA以内。所以做低功耗项目，原理图设计时就得考虑：调试接口、状态LED、外部传感器，必须允许单独断电。
4.2 不同状态下的实测电流
同一块板子、同一个固件，我分别测了以下几种状态：
| 状态 | 条件 | 实测平均电流 |
|---|---|---|
| Active（240MHz，Wi-Fi收发） | 持续TCP发送数据 | 96mA |
| Active（160MHz，Wi-Fi空闲） | 连接路由器但无数据收发 | 32mA |
| Modem-sleep（CPU运行，Wi-Fi省电） | 空闲任务运行，未启用Light-sleep | 22mA |
| Light-sleep（Wi-Fi保持连接） | 定时器10秒唤醒，期间无数据收发 | 0.9mA |
| Light-sleep（Wi-Fi保持连接） | GPIO唤醒等待，无定时器 | 0.8mA |
| Deep-sleep | RTC定时器唤醒，Wi-Fi关闭 | 20uA |
从数据能看出来，同样是Wi-Fi保持连接，从Modem-sleep的22mA降到Light-sleep的0.9mA，缩小了超过20倍。如果拿Active状态来比，差距接近100倍。
一个很重要的说明：0.9mA不是纯粹的芯片睡眠电流，它包含了Wi-Fi模块在每个Beacon周期（100ms）醒来监听一小段的高频脉冲电流，把这一小段脉冲平均下来才是0.9mA。换一个路由器，Beacon间隔如果不同，或者信号环境差导致射频发射功率升高、重传增多，这个平均值也会跟着涨。我在信号较差的环境里测过，Light-sleep平均电流能升到1.8mA左右，依然属于可接受范围。
4.3 这个功耗水平能撑多久
按一个1000mAh的锂电池来算，如果设备一直处于Light-sleep保持Wi-Fi在线、每小时被服务器唤醒一次做数据交互（每次交互5秒，电流按60mA算），那么一天的功耗大概是：
- Light-sleep待机功耗：0.9mA × 24h = 21.6mAh
- 唤醒交互功耗：60mA × 5s × 24次 / 3600 = 2mAh
- 合计约 23.6mAh/天
理论上1000mAh电池可以撑40天以上。如果只用Modem-sleep而不进Light-sleep，仅待机一项就是22mA × 24h = 528mAh，两天不到就没电了。这就是开篇说的“续航翻倍”——实际上远不止翻倍，是数量级的提升。
当然这只是理论续航，电池自放电、DCDC转换效率、温度影响都没算进去，但作为方案选型参考已经足够了。对于智能开关、温湿度传感器、门窗传感器、空气质量监测仪这类不需要频繁通信的设备，这个功耗水平意味着充一次电用一两个月完全可行。
5. 避坑指南：让Light-sleep跑得稳，这几个坑千万别踩
5.1 功耗不降反升的元凶：外设供电、GPIO浮空、LED指示灯
软件配置全对了，电流还是下不去，十有八九是硬件层面的漏电。
第一个坑是外设一直供电。很多传感器模块、显示屏背光、电平转换芯片在空闲时并不自动休眠，依然在消耗电流。比如一个简单的OLED屏，背光加驱动芯片轻松吃掉5-10mA，直接毁掉你所有功耗优化成果。低功耗设计一开始就要把外设供电规划好，用MOS管或者负载开关单独控制，睡眠时彻底断电。
第二个坑是GPIO浮空。某个引脚既没接外设也没配置上下拉，处于高阻浮空状态，引脚电压在0V到3.3V之间抖动，CMOS输入端就会产生额外的漏电流。建议把所有未使用的GPIO统一配置为输入下拉或输出低电平，别偷懒。
第三个坑是状态LED。调试用的电源指示灯、Wi-Fi状态灯在正常工作时看着方便，量产时统统去掉，或者用MCU的GPIO控制、只在需要时点亮。
另外还要注意，串口日志输出本身也是一项功耗来源。ESP_LOGI会让UART持续工作，如果通过UART输出了大量的日志，芯片很难进入深度睡眠。产品化阶段建议关闭日志输出，或者只在调试构建里开启。
5.2 Wi-Fi掉线和重连风暴
Light-sleep本身不会导致Wi-Fi频繁断线，但有几个因素会让它变得不稳定。
第一个是RF校准。ESP32做Wi-Fi收发前通常会自动做RF校准，这个操作比较耗时间和电流。在Light-sleep场景下，频繁的校准会打断低功耗状态，甚至导致唤醒时间变长。官方提供了配置项，可以把校准结果保存到NVS，重启后直接加载，跳过校准过程。在menuconfig的Component config → Wi-Fi → RF calibration里可以设置，选Auto或None（当已保存校准值时）。
第二个是路由器的Beacon周期不标准。有些路由器为了省电或优化性能，Beacon间隔会被拉长到200ms甚至300ms。ESP32的Modem Sleep默认按标准100ms周期来定时唤醒，路由器Beacon不按套路出牌，就可能出现漏听Beacon的情况，设备以为自己还在线，但路由器已经把它踢下线了。
解决办法是在初始化时设置Beacon监听超时时间，让设备在较长时间没收到Beacon后主动重新连接：
wifi_config_t wifi_config = { .sta = { .ssid = WIFI_SSID, .password = WIFI_PASS, .threshold.authmode = WIFI_AUTH_WPA2_PSK, // 单位是毫秒，表示Beacon丢失多久后认为连接失效 .listen_interval = 3, }, }; esp_wifi_set_config(WIFI_IF_STA, &wifi_config);listen_interval的单位是Beacon周期（默认100ms），设为3表示每3个Beacon周期醒来监听一次，也就是300ms。这是个双刃剑：间隔越大越省电，但实时性越差、掉线风险越高。实际项目中要根据你的交互频率来平衡。
第三个坑是重连风暴。如果信号弱或者路由器重启，Wi-Fi断开后触发WIFI_EVENT_STA_DISCONNECTED，你的处理函数里又马上调用esp_wifi_connect()，就会形成一个快速重连循环，每次重连都伴随着扫描、认证、DHCP，电流飙高。合理做法是断线后先延时几秒再重连，或者做指数退避：
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_DISCONNECTED) { ESP_LOGW(TAG, "Disconnected, reconnect after 3s..."); vTaskDelay(pdMS_TO_TICKS(3000)); esp_wifi_connect(); } }5.3 唤醒之后任务跑飞
从Light-sleep唤醒后，高频时钟重新启动、CPU恢复运行，但有些外设的状态并不会自动恢复。比如I2C总线上的传感器，睡眠期间如果总线上有电平变化，唤醒后驱动可能直接超时。因此唤醒后的处理函数里，建议对关键外设做一次重新初始化，或者至少在每次读取数据前检查设备是否正常响应。
另外，如果使用了UART唤醒，日志输出可能会把你搞晕：你在串口终端里看到系统被某个字符唤醒了，但代码其他部分还没准备好，这时如果紧接着调用printf，可能会丢字符或者卡死。为了避免这类问题，UART唤醒的使用时机要设计好，一般不做日常唤醒源，主要用于调试。
我在实际项目中还遇到过一个问题：Light-sleep期间，连接的传感器通过中断引脚（连到某个GPIO）触发唤醒，但GPIO唤醒的触发条件是电平，如果唤醒后没有及时清除中断标志，或者传感器一直保持低电平，设备唤醒后会反复被触发，根本没法进入睡眠。解决办法是在中断处理里把引脚配置成上拉输入、或者增加去抖逻辑。
5.4 蓝牙和Wi-Fi能一起用吗
这个问题被问得非常多。结论是：硬件上ESP32支持Wi-Fi和蓝牙共存，但在低功耗场景下，两者同时工作在Light-sleep里会有明显的互相影响。
Light-sleep要求射频在Beacon周期定时醒来，而BLE（低功耗蓝牙）也有自己的连接间隔和唤醒机制。两者叠加，射频唤醒频率成倍增加，整机电流自然会上升。如果BLE连接间隔很短（比如7.5ms），Light-sleep基本进不去，功耗跟Modem-sleep差不多。
我的建议是：如果项目必须同时保持Wi-Fi和BLE连接，先明确主次。以BLE为主、Wi-Fi周期上报的应用，可以让Wi-Fi在不通信时完全断开，只在需要时重连；以Wi-Fi实时在线为主的应用，BLE只在本地配网或近距离调试时启用，配网完成后直接关闭BLE。
5.5 常见问题速查表
| 现象 | 原因 | 解决办法 |
|---|---|---|
| Light-sleep电流仍高达4mA以上 | 板载USB串口芯片、LED、LDO静态电流 | 断开调试器件，单独给模组供电 |
配置了light_sleep_enable但不进睡眠 | 持有了频率锁或外设锁 | 检查esp_pm_lock_acquire/release是否成对释放 |
| Wi-Fi频繁掉线 | Beacon监听间隔过长、路由器踢人 | 调整listen_interval，开启自动重连退避 |
| GPIO唤醒后反复触发 | 唤醒电平一直有效，未解除 | 改用边沿触发，或在中断里重新配置引脚 |
| 唤醒后外设I2C读写失败 | 睡眠期间外设状态异常 | 唤醒后重新初始化外设驱动 |
| 实测电流波动大 | 路由器Beacon周期、信号环境变化 | 避免在信号弱的环境测试，统一测试环境 |
写在最后的实际体会
Light-sleep这个功能我前前后后调了快两年，最大的体会是：低功耗不是某一个函数、某一个配置能解决的，它是一套系统设计。软件上要把电源管理、Wi-Fi省电模式、唤醒源、外设状态机全部理顺，硬件上要把没用的调试器件拿掉、外设供电管好。两者缺一个，电流数字都会给你颜色看。
最后分享一个小技巧。如果你做的是周期性上报的设备，可以把定时唤醒周期和路由器的DTIM周期对齐，比如设置成300ms的整数倍。这样做的好处是每次醒来都有大概率赶上DTIM窗口，路由器缓存的广播包能一次性收到，不会因为错过DTIM再等一轮，长期运行下来平均电流会更稳定。我目前的设备在稳定的家庭路由器环境下，Light-sleep平均电流已经压到了0.7mA左右，这个数字在一年前我是不敢想的。
所以别被Deep-sleep包打天下的思路限制住，Wi-Fi在线的低功耗设备，Light-sleep才是那个真正能把在线和续航同时保住的方案。
