跳转至

MacBook Air 合盖异常掉电与蓝牙唤醒风暴排查报告

生成时间: 2026-08-13T00:11:41+0800

1. 问题描述

MacBook Air 在充满电后持续合盖约 18 小时，电量从 100% 降至 47%。用户期间没有主动使用电脑，电池健康状态正常，因此需要确认是电池故障、应用后台耗电，还是系统未能正常深睡。

2. 环境和范围

  • 设备：MacBook Air（Mac17,3，Apple M5）
  • 系统：macOS 26.6.1（25G76）
  • 无线芯片：Apple N1，蓝牙固件 1.544.0.0
  • 电池：循环 29 次、健康“正常”、最大容量 100%
  • 附近设备：同一 Apple 账户的 Mac mini、Huawei FreeBuds Pro 3、Logitech M720 等
  • 排查范围：只读检查 pmset、电源管理 ASL 日志、统一日志及蓝牙状态；未改 Wi-Fi、Handoff 或 Mac mini 配置

设备序列号和蓝牙地址未写入本报告。

3. 症状和复现

异常夜晚的电量曲线在屏幕关闭期间持续下降。活动监视器曾显示 ChatGPT 的“12 小时电源”很高，但该值是相对能耗评分，不能直接证明它唤醒了系统。

系统日志显示，18:00 至次日 12:02 共发生 2,275 次 DarkWake，约 126 次/小时。绝大多数唤醒原因相同：

DarkWake from Deep Idle [CDNP] :
due to smc.sysState.Wake(0x70070000)
wifibt SMC.OutboxNotEmpty centauri-beta

机器不断执行“深睡 → 蓝牙/SMC 后台唤醒 → Maintenance Sleep → 再次深睡”，平均约每 28.5 秒一次。屏幕直到用户开盖时才真正点亮，排除了合盖传感器失效和人为开屏。

4. 排查时间线

  1. 检查电池：循环次数低、健康正常、最大容量 100%，排除明显电池衰减。
  2. 检查睡眠断言：未发现能够解释整夜问题的普通应用防睡眠断言。
  3. 分析电源日志：定位到数千次 wifibt/SMC.OutboxNotEmpty/centauri-beta DarkWake。
  4. 对比外设使用时间：04:00 关闭 M720、开始使用 FreeBuds 后，04:00–06:59 每小时仅 4–5 次正常唤醒；07:03 后风暴才重新出现。因此 FreeBuds 持续连接不是主要解释。
  5. 分析蓝牙统一日志：07:03 后出现蓝牙控制器 HostwakeReport、扫描停止后仍收到设备发现事件等异常；随后明确记录同一 Apple 账户的 Mac mini 建立加密 BLE/GATT 连接。
  6. A/B 验证：2026-08-12 12:37:44 关闭 MacBook Air 蓝牙，保持 Wi-Fi、Handoff 和 Mac mini 不变。

5. 根本原因

已确认的根因范围：MacBook Air 的蓝牙路径引发睡眠唤醒风暴。

关闭本机蓝牙后，异常唤醒原因从数千次降为零，合盖耗电恢复正常，因此根因不是 ChatGPT、Clash Verge、电池老化或普通 Power Nap。

高概率但尚未单独完成 A/B 证明的具体触发器：同一 Apple 账户的 Mac mini 邻近通信。 日志明确出现 Mac mini 的 BLE/GATT 建连、加密和断开，以及以下服务组件：

CloudPairing
WirelessProximity
Wiprox
FindMyBluetooth
SPLocalBeaconManager
WPDSearchPartyAgent

最合理的解释是：Mac mini 的正常 BLE/连续互通广播触发了 MacBook Air 的 Apple N1 蓝牙控制器或 macOS 26.6.1 睡眠状态机缺陷，进而被异常放大为高频 DarkWake。Mac mini 更像外部触发条件，MacBook Air 的 N1/macOS 处理异常更像底层缺陷。

6. 已做更改

  • 用户关闭了 MacBook Air 蓝牙，并决定日常保持关闭。
  • 未修改 Wi-Fi、Handoff、Power Nap、tcpkeepalive、SleepServices 或 Mac mini 设置。
  • 未卸载 ChatGPT、Clash Verge、FreeBuds 或 M720。

该规避措施的影响是无法使用本机蓝牙耳机、鼠标、键盘，以及部分 Handoff、通用控制、Apple Watch 解锁和附近设备功能。

7. 验证

关闭蓝牙后的观测结果：

指标 蓝牙开启、异常夜晚 蓝牙关闭后
观察时长 约 18 小时 约 11.5 小时
DarkWake 2,275 次 40 次
平均 DarkWake 约 126 次/小时 约 3.5 次/小时
wifibt/SMC.OutboxNotEmpty/centauri-beta 大量出现 0 次
合盖电量 100% → 47% 基本不变

DarkWake 频率下降约 97%。关闭蓝牙后保留的唤醒主要是正常的 rtc/SleepService、Maintenance 和推送维护；从 17:46 到次日 00:02，电源日志持续报告电量为 85%，没有出现可见百分点下降。

8. 调试中遇到的问题

  • 活动监视器“12 小时电源”容易误导：它不能直接映射为耗电百分比，也不能证明某个 App 是唤醒发起者。
  • pmset -g log 数据量很大，直接读取会产生数十 MB 输出；最终改为按日期读取 /var/log/powermanagement/*.asl 并按时间和事件类型过滤。
  • 蓝牙日志会隐藏部分设备信息，不能仅凭通用 wifibt 字样锁定具体外设；需要结合 GATT 建连日志和分时 DarkWake 统计。
  • FreeBuds 最初看似可疑，但 04:00–06:59 使用耳机期间睡眠正常，属于被时间线证伪的假设。

9. 可复用经验

  • 合盖异常掉电应优先比较“本地健康 → 睡眠断言 → DarkWake 次数 → 唤醒原因 → 外设 A/B”，不要只看活动监视器累计评分。
  • wifibt/SMC.OutboxNotEmpty 高频出现时，先做可逆的蓝牙关闭实验；一小时通常已经足够区分每小时个位数和上百次唤醒。
  • 必须区分“外部触发器”和“底层缺陷”：附近设备广播可能正常，真正异常的是睡眠中的 Mac 对事件处理失控。
  • 若以后需要恢复蓝牙，可做短时对照：FreeBuds 入盒、M720 关闭，仅切换 Mac mini 蓝牙，分别合盖 30–60 分钟。
  • 若系统更新后复发，可收集 sysdiagnose 并向 Apple 提交 Apple N1、HostwakeReport 和 centauri 相关证据。

10. 附录：可复用命令

查看电池健康与当前电量

system_profiler SPPowerDataType
pmset -g batt

查看当前睡眠设置和防睡眠断言

pmset -g custom
pmset -g assertions

查看近期睡眠与唤醒原因

pmset -g log | grep -E 'DarkWake|Entering Sleep|FullWake|Wake Requests'

查看蓝牙控制器状态

system_profiler SPBluetoothDataType

统计指定电源日志中的异常唤醒

/usr/bin/syslog -f /var/log/powermanagement/YYYY.MM.DD.asl 2>/dev/null \
  | grep -c 'wifibt SMC.OutboxNotEmpty centauri-beta'

检查蓝牙与附近设备日志

/usr/bin/log show --start 'YYYY-MM-DD HH:MM:SS' \
  --end 'YYYY-MM-DD HH:MM:SS' --style compact --info --debug \
  --predicate 'process == "bluetoothd" OR process == "audioaccessoryd"'