LE避坑：低功耗不是默认省电
LE避坑要先记住一句话：协议叫Low Energy，不代表你的产品自动低功耗。真正耗电的往往不是发那几个字节，而是广播间隔、连接参数、唤醒频率、重连策略这些细节。坑都藏在默认配置里。
总述：LE省电靠“少醒、快发、快睡”
蓝牙LE的底层逻辑很朴素：设备大部分时间睡眠，偶尔醒来广播或连接，传完数据马上回睡。只要你让它频繁醒、长时间连、反复重试，电池一样掉得飞快。
很多新手以为换成BLE芯片就解决功耗，结果一节纽扣电池两周耗光。问题通常不在芯片，而在参数和业务节奏。
坑一：广播间隔设太短
广播间隔越短，越容易被手机扫到，也越耗电。开发时设100ms很爽，手机一打开就发现设备；量产还这么设，电池会哭。传感器、标签类设备常见做法是平时1秒到几秒广播一次，进入配对模式再临时加快。
更稳的设计是分状态：未绑定时快广播，已绑定后慢广播；有按键或运动触发时短时间快广播，超时自动降频。
坑二：连接参数照抄示例
连接间隔、slave latency、 supervision timeout决定了连接状态下的耗电和响应速度。示例工程为了演示灵敏，经常参数偏激进。你拿去做电池设备，就等于让芯片频繁醒来陪手机聊天。
比如一个温度计，每30秒更新一次数据，没必要保持很短连接间隔。把连接设计成“需要时连接、同步后断开”，常常比长期保持连接更省。
坑三：MTU越大越好是误解
MTU大能减少分包，对固件升级、批量数据有用。但如果你每次只发几个字节，追大MTU没有意义，还会增加协商和缓存复杂度。LE优化不是把所有参数拉满，而是匹配数据形态。
我的经验是：状态值、开关指令先用简单特征值；日志、升级包再单独设计传输流程，别把日常通信搞成大而全协议。
坑四：安全只做“能连上”
门锁、医疗、资产标签这类设备，不能只靠隐藏服务UUID或固定口令。LE本身提供配对、绑定、加密，但你还要考虑业务层鉴权。固定token写在App里，被抓包一次就可能失效。
更可靠的方式是首次绑定建立信任，后续关键操作做随机挑战；敏感数据不要明文广播；丢失设备要能解绑或吊销。安全设计越晚补，代价越高。
总结：先测电流曲线，再谈优化
LE避坑的核心不是背参数，而是拿电流表看设备什么时候醒、醒多久、为什么醒。平均电流=每次唤醒能量×唤醒次数，再加睡眠漏电。这个账算清楚，优化方向就很直。
做原型时至少测三组：广播状态、连接状态、睡眠状态。只看App显示正常，不看功耗曲线，等于闭着眼做低功耗。
推荐阅读
常见问题
蓝牙LE为什么还会很耗电？
常见原因是广播太频繁、连接间隔太短、长时间不断连、传输失败反复重试，或者硬件睡眠电流没压下来。
LE设备广播间隔设置多少合适？
没有固定值。配对阶段可设100ms到300ms提高发现速度，正常运行可放到1秒以上，传感器类还可以更慢。
LE安全只靠配对够吗？
普通数据同步基本够用；门锁、支付、医疗等高风险场景，还需要业务层鉴权、随机挑战和权限管理。