做低功耗产品，被0.3µA这个数字“骗”过的人不止我一个。拿到一块STM32L0的板子，一看数据手册：Stop模式标称电流0.29µA，真把代码写进去，万用表一量——好家伙，870µA。本来想着“睡一觉”能省电，结果这一觉睡得比清醒时候还费电。问题出在哪？不是芯片不行，而是低功耗用法远不止“调用一个进入Stop的函数”那么简单。这篇就围绕STM32L0的低功耗设计聊点实在的：模式怎么选、唤醒源怎么配、电流到底怎么测、GPIO和外设还有哪些隐形漏电点。适合正在做电池供电物联网节点、传感器采集设备的开发者，也适合第一次碰低功耗MCU、想把平均功耗真正降下来的人。
1. 低功耗设计的核心口径：先定需求，再选模式
1.1 低功耗不是“越省越好”，而是“平均功耗越低越好”
很多新手拿到低功耗芯片，第一反应是找功耗最低的模式，直接Standby。但Standby一进，SRAM全丢，唤醒等于复位，所有运行上下文都没了。如果你的产品还需要保留状态、快速恢复、甚至定时采集上报，这个方案就会非常痛苦。
低功耗设计要看的从来不是“某一刻的瞬时电流”，而是整个运行周期的平均电流。我用一个例子说明：一个温湿度采集节点，每10秒醒一次采数上报，每次工作大约5ms，工作电流5mA；然后进Stop模式10秒，电流1.5µA。算一下平均电流：
- 工作部分：5mA × 5ms ÷ 10s = 2.5µA
- 休眠部分：1.5µA × (10s - 5ms) ÷ 10s ≈ 1.499µA
- 总平均电流约4µA
这就是10秒周期下的真实平均功耗。也就是说，即便Stop电流只有1.5µA，但工作功耗和工作时间一样会决定整体寿命。反过来，如果某一次测量需要3ms才能稳定，你就要算清楚到底是2ms轮询模式下平均功耗高，还是20ms睡醒一次、每次稳定后更划算。所以拿到项目的第一步，永远是写下需求：采集周期多少、每次工作多久、能不能容忍唤醒延迟、数据要不要掉电保存。
1.2 STM32L0在低功耗MCU里的定位
STM32L0是主打静态功耗的Cortex-M0+内核系列，最高主频32MHz，工作电压可以低到1.65V（某些型号甚至更低），SRAM从2KB到20KB不等，Flash从8KB到192KB不等。相比追求更高性能的L4或G0系列，L0的定位非常明确：电池能用几年、常年挂在传感器节点上、不在乎算力、只在乎每一微安。
同一颗L0下面也有不同细分型号，我在实际选型中重点关注这几个差异：
| 关注项 | 入门低配（如L011） | 中档（如L053） | 高端（如L072/L082） |
|---|---|---|---|
| Flash/RAM | 较小，适合简单节点 | 适中 | 较大，可跑协议栈 |
| LPUART | 部分型号没有 | 多数有 | 标配 |
| RTC | 多数有 | 有 | 有 |
| 内部参考电压VREFINT | 有 | 有 | 有 |
| ADC分辨率 | 12位 | 12位 | 12位 |
| 典型场景 | 简单IO采集、唤醒计数 | 传感器采集+低功耗串口 | 物联网模组管理、复杂状态机 |
选型原则很粗暴：先把工程需要的外设列表写出来，再查它是否在Stop模式下还能工作。比如你希望休眠时LPUART能监听外部指令，那就要确认目标型号的LPUART支持Stop模式唤醒，否则就得走外部中断唤醒方案。这一条没理清，后面直接焊板子就是返工。
2. 工作模式与寄存器操作：把L0的“睡眠”玩明白
2.1 六种模式的功耗分级与选择逻辑
STM32L0可不止Sleep、Stop、Standby三种，完整分起来有六种工作状态。我按功耗从高到低排了一张表，方便对照：
| 模式 | 内核是否运行 | SRAM保持 | 电流量级（与规格书相关） | 唤醒时间量级 | 适用场景 |
|---|---|---|---|---|---|
| Run | 是 | 是 | 动态电流，约88µA/MHz量级 | 无 | 正常处理 |
| Low-power Run | 是 | 是 | 约几µA到十几µA，看外设和时钟 | 无 | 低速处理、降低动态功耗 |
| Sleep | 否 | 是 | 约几µA到十几µA | 纳秒到微秒级 | 短暂等待 |
| Low-power Sleep | 否 | 是 | 约几µA以下 | 微秒级 | 低频等待事件 |
| Stop | 否 | 是 | 约0.3µA~1µA级别（带RTC稍高） | 几微秒到几十微秒 | 间歇采集节点主选模式 |
| Standby | 否 | 否（仅备份寄存器保留） | 约0.3µA级别 | 几十微秒到百微秒以上 | 极端省电、可接受复位唤醒 |
实际工程里，我90%的电池节点都用Stop模式。原因很简单：SRAM保住、状态不断、RTC或外部事件能唤醒，唤醒时间也快。只有两种情况我会上Standby：一是系统确实是“数据采完就完，下次开机电量重来”；二是为了更进一步降几百纳安，且允许唤醒后重新初始化全部状态。
Low-power Run模式容易被忽略，其实是跑低速任务时的好工具。把主频降到低值，配合低功耗调节器，可以在“还在执行代码”的情况下把电流压到几µA级别。你要做的只是把时钟源切到合适的低频时钟，并让内核低速跑完一小段逻辑，再回到Stop。
2.2 关键寄存器与HAL进入Stop的标准姿势
在STM32L0上，进入Stop模式的核心是PWR_CR寄存器中的两个位：一个控制深睡眠下电压调节器是否进入低功耗模式（对应HAL里的PWR_LOWPOWERREGULATOR_ON），另一个控制是进入Stop还是Standby。HAL库里最常用的写法是这样：
/* 进入Stop模式，WFI等待唤醒 */ HAL_PWR_EnterSTOPMode(PWR_LOWPOWERREGULATOR_ON, PWR_STOPENTRY_WFI);这个调用有意义的地方在于两件事：一是把电压调节器切到低功耗模式，进一步压低静态电流；二是用WFI指令让内核停住。很多人忽略一点：唤醒发生后，内核会从WFI之后的下一行继续执行，但时钟树是重新启动的，并不保证恢复到你Run模式时的频率。所以紧跟着一定要重新配置时钟：
HAL_PWR_EnterSTOPMode(PWR_LOWPOWERREGULATOR_ON, PWR_STOPENTRY_WFI); SystemClock_Config(); /* 重新初始化MSI、HSE等时钟源 */这里有个ST官方HAL库的隐含行为：HAL_PWR_EnterSTOPMode函数内部会清除唤醒标志，但如果你的项目没有用HAL，或者用了早期版本固件，多次进出Stop后可能因为WUF标志没清干净导致唤醒行为异常。我习惯在每次进入Stop前显式清一次标志：
__HAL_PWR_CLEAR_FLAG(PWR_FLAG_WUF);这段代码放在进入Stop之前；同时，如果唤醒后还要再次进入Stop，一定要确保所有唤醒中断标志位（比如RTC唤醒标志、EXTI挂起位）都已经被读清除，否则会形成“刚睡下就被唤醒”的死循环。
2.3 WFI与WFE：选错会带来诡异问题
HAL_PWR_EnterSTOPMode的最后一个参数可以是PWR_STOPENTRY_WFI或PWR_STOPENTRY_WFE。对大多数场景来说WFI就够，它要求你启用了对应中断，唤醒后进入中断服务函数处理标志，然后回到主流程。WFE是基于事件的休眠，需要配合事件机制，比如用SEV指令或者外设事件，而不仅仅是中断。
我的个人建议：按键、RTC这类明确中断源的场景，一律用WFI。WFE容易在调试事件、外设事件配置不当时出现“没睡住”或者“自己醒了”的怪问题，很多新手在这里卡很久。如果你确实想用WFE，先把Cortex-M0+的事件寄存器和外设事件映射关系查清楚，再动手写。
2.4 Standby模式的代价与备份寄存器
进入Standby模式：
HAL_PWR_EnableWakeUpPin(PWR_WAKEUP_PIN1); HAL_PWR_EnterSTANDBYMode();一旦进入，主SRAM里的内容全部丢失，只有备份寄存器和RTC寄存器还能留住一点数据。所以如果需要跨休眠保存计数、校准值、状态位，就把这些数据写到RTC备份寄存器里：
/* 写备份寄存器 */ HAL_RTCEx_BKUPWrite(&hrtc, RTC_BKP_DR0, 0xA5A5); /* 唤醒后读取 */ uint32_t state = HAL_RTCEx_BKUPRead(&hrtc, RTC_BKP_DR0);要注意：访问备份寄存器之前需要使能PWR的DBP（Disable Backup Domain）位，否则写不进去。HAL内部通常已经处理了这一步，但如果你直接操作寄存器，别忘了。
3. 唤醒源工程化：RTC、EXTI与LPUART怎么搭才靠谱
3.1 RTC唤醒定时器：间歇采样的时间基准
电池供电的传感器节点，绝大多数走的都是“定时醒、采一下、睡回去”的路子。这个定时器我优先用RTC唤醒定时器（WakeUp Timer），而不是普通定时器，因为RTC在Stop、Standby模式下都能跑，依赖LSE或LSI时钟。
配置RTC唤醒定时器的核心代码：
/* 唤醒周期设为4秒，假设使用1Hz的CK_SPRE作为计数器时钟 */ HAL_RTCEx_SetWakeUpTimer_IT(&hrtc, 4, RTC_WAKEUPCLOCK_CK_SPRE_16BITS);这里计数值是4，得到的唤醒间隔大约是4秒。如果项目需要更长的周期，比如10分钟，就需要把计数单位放大，比如用17位预分频或者算好分频系数。建议在工程里封装一个函数，直接把“期望周期（秒）”换算成计数器值和分频配置，避免每次看到宏都重新翻手册。
实际使用中我遇到最多的问题是LSE不起振。LSE是32.768kHz晶振，一旦PCB布局不好或者负载电容不对，RTC完全不走。这种情况我建议先在正常运行状态下单独测RTC是否计数，再进低功耗模式。不要等焊到电池上才发现“明明休眠了，电流却不降”，可能只是RTC一直在抢主频。
RTC唤醒中断回调：
void HAL_RTCEx_WakeUpTimerEventCallback(RTC_HandleTypeDef *hrtc) { wakeUpFlag = 1; /* 置标志，主循环处理采集 */ }要注意：中断服务函数里尽量少干活，置个标志让主循环处理。低功耗场景下主循环本来就是事件驱动的，这样最干净。
3.2 外部中断与GPIO的唤醒细节
外部中断是我第二常用的唤醒源。场景包括：低功耗按键、门磁开关触发、传感器比较器输出跳变、外部串口设备拉一下IO等。配置比较简单：
HAL_GPIO_WritePin(GPIOA, WAKE_PIN, GPIO_PIN_RESET); GPIO_InitTypeDef gpio = {0}; gpio.Pin = WAKE_PIN; gpio.Mode = GPIO_MODE_IT_RISING; gpio.Pull = GPIO_PULLDOWN; HAL_GPIO_Init(GPIOA, &gpio); HAL_NVIC_SetPriority(EXTI4_15_IRQn, 0, 0); HAL_NVIC_EnableIRQ(EXTI4_15_IRQn);这段代码里我把唤醒引脚配置为上升沿触发，并开启内部下拉。很多设计会觉得“外部已经有上拉/下拉了，内部就不配了”，这不行。低功耗模式下，外部电阻网络是常开的漏电路径，上拉10k电阻在3.3V下就白白贡献了330µA？不是，实际上上拉电阻的电流是持续的，虽然可能被IO内部电路阻断，但电阻本身的压差电流会流过你的供电回路，这在精打细算的µA级别项目里是致命的。所以要么把外部上下拉电阻去掉，要么选择内部上下拉后进入Stop前保证电平是确定状态。
进入Stop之前，我必须把所有可能浮空的GPIO全部配置成确定状态。经验值是：不用但存在的外设引脚，直接配置为模拟模式（GPIO_MODE_ANALOG），这是大多数STM32在低功耗模式下漏电最小的做法。输入下拉或输出低不一定最省。
3.3 LPUART与低功耗ADC：两个容易被忽略的唤醒途径
LPUART是个好东西。STM32L0的LPUART在Stop模式下可以借助低速时钟继续监听总线，外部发来起始位就能把芯片唤醒。这意味着你的系统不需要额外拉一根唤醒IO线，保存了“串口即唤醒”的产品逻辑。
我通常这样用：系统进入Stop前，LPUART保持使能并处于接收等待状态，RTC定时作为后备；一旦外部主机发指令，LPUART检测到起始位就产生唤醒事件。唤醒后读取串口数据，解析完再决定是继续睡还是干活。要注意LPUART在Stop模式下使用的时钟必须是LSE或HSI，这两个时钟在Stop模式下都要保持开启，所以对应功耗也要算进去。
低功耗ADC唤醒方式同样被低估。STM32L0的ADC支持在Stop模式下自动采样，不需要内核参与，采样完成后再唤醒CPU。适合那种“日常几乎不跑代码、电压或光敏信号变了就起来处理”的场合。但这个功能对ADC时钟、采样触发源和比较器配置有额外要求，不是所有L0型号都支持相同用法，开发前要翻对应型号参考手册“Low-power modes”章节，别拿L053的代码直接烧到L011上。
4. 电流测量与功耗排查：标称0.3µA，实测凭什么几十µA
4.1 三种实测电流的手段，各有各的坑
做低功耗，最不能省的工具就是能测µA级电流的仪器。我常用三种办法：
第一种，万用表串联法。把数字万用表拨到µA档，串在电池正极和板子供电之间。这个方法最直接，但有两个坑：一是万用表的内阻不容忽视，µA档内阻可能到几百甚至上千欧，低功耗系统工作电压本来就不高，串进去可能直接让系统复位；二是系统动态电流变化很快，万用表读数只反映平均或最近一瞬的值，看不到唤醒瞬间的峰值。所以万用表适合粗测和长时间平均功耗统计，不适合看瞬态波形。
第二种，采样电阻加示波器。在电源输入路径串一个精密电阻，比如10Ω或100Ω，用示波器测量电阻两端压差，通过I等于压降除以电阻算出电流。1µA电流在100Ω电阻上产生100µV压降，低噪声示波器是能分辨的。这个办法能看到完整的电流波形，包括唤醒尖峰和稳定时间，是排查问题的利器。
第三种，专用功耗分析仪或电流探头。精度高，能测到nA级别，适合项目量产前做最终功耗验证。缺点只有一个，贵。个人开发者或小团队不一定常备，可以用前两种组合替代。
4.2 隐形漏电杀手排查清单
我说个真实经验：一块板子，MCU已经进入Stop，电流还是19µA。查了半天，最后发现是板上的LED指示灯没有做电源切断，只是把IO拉低了，而LED负端直接接地，LED钳位二极管在低电压下产生了不明漏电。这种问题不亲自踩一次，根本想不到。
下面这份排查清单是我在实际调试中反复用的：
| 漏电源头 | 具体表现 | 处理方式 |
|---|---|---|
| GPIO悬空 | 输入悬空电平漂移，IO内部漏电 | 全部设为模拟模式或确定上下拉 |
| 板载外设常供电 | 传感器、运放、电平转换芯片还在消耗电流 | 使用MOS管或负载开关单独断电 |
| LED灯漏电 | IO拉低但LED仍有回馈电流 | 彻底断开LED电源或串联电子开关 |
| LDO静态电流 | 板载LDO自身耗电几十µA | 选择低静态电流LDO（Iq要小于总预算） |
| 调试接口连接 | SWD调试器供电并拉高引脚 | 拔掉调试器，量产板不加探针 |
| 外部上下拉电阻 | 常开电阻持续消耗电流 | 能不接就不接，或用大阻值（1M以上） |
| 助焊剂残留 | PCB表面形成微漏电通路 | 洗板水清洗、助焊剂少涂、涂完清干净 |
| VREFINT内部参考 | 某些配置下内部参考自动开启 | 按参考手册关闭不需要的内部参考电路 |
| BOR/复位电路 | 外部复位芯片静态电流 | 选低功耗复位芯片，或检查内部BOR配置 |
| 单独LED没有串接限流电阻直接接IO | GPIO输出高电平驱动LED时漏流 | 这种其实好查，电流明显，但容易忽略 |
最容易忽略的是“板级漏电”而不是“芯片漏电”。芯片本身吃了0.3µA，但板上一个LDO吃了5µA，一个电平转换吃了2µA，一个LED漏电吃了3µA，加起来就完全不是一回事了。
4.3 逐步加载法定位功耗异常
我调试低功耗板的流程非常固定，谁来了都能复现：
第一步，只焊MCU最小系统，包括电源、复位、晶振、下载接口。烧一个只进Stop的空的main函数，测底电流。如果这个都达不到标称值附近，说明MCU最小系统配置有问题，先解决这个。
第二步，逐步加载外设。每焊接或使能一个模块，测一次电流。这个“加一样，测一样”的方法看起来笨，但绝对有效。你一眼就能看出哪个模块把电流拉高了。
第三步，把所有外设代码打开，但让外设进入独立低功耗状态。例如传感器配置为shutdown、ADC配置为断电、串口关闭接收。测一下整板休眠电流。
第四步，再看唤醒后的工作电流。工作电流也影响平均功耗，用示波器看波形，确认唤醒后的处理时间是否被不必要地拉长。我见过一个项目，唤醒后初始化Flash等待了200ms，白白吃掉一大块平均功耗，优化后变成10ms。
我用这个方法帮一个朋友排查过某个传感器板，原本休眠电流28µA，按照“先最小系统、后逐外设”的流程，最终定位到是传感器板上的DC-DC在轻载时进入了脉冲丢波模式，导致电流异常。很多时候问题的根源根本不在MCU。
5. 实战：10秒采集一次的温湿度传感器节点
5.1 状态机与需求拆解
我想做一个真实的示例，方便大家照着搭。需求是这样：电池供电的温湿度节点，每10秒采集一次温湿度，采集完成后通过串口（或无线模块，这里先简化成串口）上报，其余时间进入Stop模式。
状态机很简单：
- 状态A：初始化，配置时钟、GPIO、RTC、传感器
- 状态B：Stop休眠，RTC定时10秒唤醒
- 状态C：唤醒后，打开传感器电源，等待传感器稳定，启动ADC采集
- 状态D：处理数据、上报、关闭外设电源，回到状态B
这里要注意两条边界：第一，从Stop唤醒回到Run，先重配时钟再访问外设，否则外设时钟树不对，读取数据就是乱码；第二，进入Stop前必须保证所有打开的外设已关闭，否则外设还在耗电，休眠电流必然偏高。
5.2 核心代码框架
先初始化RTC唤醒定时器：
void RTC_WakeUp_Init(void) { HAL_RTCEx_SetWakeUpTimer_IT(&hrtc, 10, RTC_WAKEUPCLOCK_CK_SPRE_16BITS); }主循环的逻辑：
while (1) { if (wakeUpFlag) { wakeUpFlag = 0; /* 唤醒后第一件事：恢复时钟 */ SystemClock_Config(); /* 采集并上报 */ sensor_power_on(); HAL_Delay(2); /* 等待传感器稳定 */ float temp = read_temperature(); float humi = read_humidity(); sensor_power_off(); report_data(temp, humi); /* 准备再次进入Stop */ clear_peripheral_state(); __HAL_PWR_CLEAR_FLAG(PWR_FLAG_WUF); HAL_PWR_EnterSTOPMode(PWR_LOWPOWERREGULATOR_ON, PWR_STOPENTRY_WFI); } else { __WFI(); } }这个框架看起来简单，但每个函数都有低功耗含义。sensor_power_on和sensor_power_off之间，中间的HAL_Delay(2)是等待传感器稳定，时间不能拍脑袋，要看传感器数据手册里的上电稳定时间。有的传感器要几十ms，那就必须等，不能为了“省时间”提前读，读出来错误数据更麻烦。
report_data也不仅仅是打印，可能还要通过无线模块发送。无线发送是典型的“高电流短时间”操作，最好一次性填满发送缓冲区、关掉无线模块的等待时钟，快速发完再进Stop。如果无线模块有独立使能引脚，发送完立刻断电。无线模块不吃电这一点，能直接把休眠电流按比例砍掉一大截。
5.3 实测结果与电池寿命估算
按照前面说的测量方法，我在一块测试板上实测的结果大概是：
| 阶段 | 电流 | 持续时间 |
|---|---|---|
| Stop休眠（含RTC和LPUART） | 约1.8µA | 10s |
| 唤醒+时钟恢复 | 约5mA | 约1ms |
| 传感器上电+稳定 | 约3mA | 2ms |
| 采集转换 | 约4mA | 1ms |
| 串口发送数据 | 约6mA | 1ms |
平均电流计算：
- 1.8µA × 10s ≈ 18µAs（休眠部分）
- 5mA × 1ms + 3mA × 2ms + 4mA × 1ms + 6mA × 1ms ≈ 21µAs（工作部分，注意单位换算：5mA×1ms=5µAs，3mA×2ms=6µAs，4mA×1ms=4µAs，6mA×1ms=6µAs，合计21µAs）
- 总电量约39µAs ÷ 10s ≈ 3.9µA
这个平均电流只是一个粗略估算，实际还要考虑传感器休眠电流、无线模块待机电流、电池自放电和环境温度影响。但量级已经出来了：一个10秒周期的采集节点，平均4µA左右。如果用一块200mAh的锂亚电池，理论寿命大概是200mAh ÷ 0.004mA ≈ 50000小时，约合5.7年。注意这是理想值，去掉电池自放电、低温容量衰减、无线模块异常等，实际寿命通常打五折到七折。
想进一步优化，方向也很明确：拉长采集周期到60秒，平均电流能压到约1.5µA级别；或者在采集完成后立刻关掉传感器电源，而不是等到下一个周期才关；无线发送时如果波特率可以拉到更高，发送持续时间从几ms缩到几百µs，也能省不少。
6. 低功耗调试注意事项与经验总结
6.1 拔掉调试器再测电流，这句话值一半的调功耗时间
我在第4部分提过调试接口的影响，这里再强调一次。很多开发者用开发板或者自制板调功耗，SWD调试器一直插在板子上。调试器本身会拉高SWDIO/SWCLK，还可能给目标板供电，这时候测到的电流包含调试器的贡献，数据完全不可信。正确做法是：先用调试器烧录程序，然后拔掉调试器，用外部电源独立给板子供电再测电流。如果项目需要频繁下载，可以设计一个“调试跳帽”，下载时插上，测试时拔掉，板上留一个常闭测试点。
6.2 低功耗调试不要迷信一个“万能Sleep函数”
HAL库封装的函数确实方便，但具体的低功耗行为和你使用的芯片型号、库版本、时钟配置都有关系。比如进入Stop模式后，MSI、HSI、HSE怎么处理，是否自动关闭，不同系列配置不同。建议花一点时间，把目标型号的参考手册里“Low-power modes”章节完整读一遍，把PWR_CR、PWR_CSR、PWR_CR的LPRUN、LPDS等位逐条确认。只有理解了寄存器级行为，才能在低功耗异常时快速定位，而不是猜测。
调试时还可以用一个小技巧：找一个GPIO，在进入Stop前拉低、唤醒后立刻拉高，然后用示波器看这个GPIO的翻转间隔，确认实际唤醒周期是否准确。这个比在串口打印时间戳更可靠，因为串口打印本身就影响功耗和时序。
6.3 别忘了温度和电压对电流的影响
低功耗电流不是恒定值。锂电池电压从4.2V降到3.0V，芯片漏电会有显著变化；温度升高，PN结漏电指数级上升。数据手册上的0.29µA是在25°C左右的典型值，到了60°C环境，Stop电流可能变成几µA，正常工作。所以如果你的产品用在户外高温环境，做功耗预算时一定要按最坏温度条件补偿，而不是按25°C标称值算寿命。
6.4 低功耗设计是系统工程，不止MCU
最后说点体会。我这几年调低功耗项目，得到的最大教训是：MCU的低功耗能力只是整个系统功耗的一个底线，而不是上限。传感器选型、无线模块待机电流、电源芯片静态电流、PCB漏电流、固件唤醒时长，每一个环节都在平均功耗里投了票。STM32L0作为主控已经足够优秀，但如果你不把外设电源管理做干净，不把测量方法用对，再强的低功耗MCU也被拖下水。
个人经验建议：产品定型阶段，先在原理图上把所有模块的静态电流加一遍，得到一个纸面上的功耗预算；焊接后第一时间做“最小系统底电流测试”；软硬件联调时用采样电阻加示波器的办法观察每个阶段的电流波形；量产前再用精密设备做一轮全温区功耗测试。这一套走下来，低功耗才能从“理论可行”变成“量产可用”。
另外给新入行的朋友一个建议：先别急着上复杂的产品，拿一块L0开发板，从LED闪烁开始，跑一个带RTC唤醒的Stop模式，再用万用表量出电流变化。把这一步走通，你已经超过了很多人。低功耗没有玄学，只有一步步测出来的数据和一个个关掉漏电路径的习惯。
