本文整理自一次实际黑苹果睡眠排查过程，重点介绍如何使用 pmset 日志判断：

• 是否真正进入睡眠
• 是否出现“刚睡下就自动唤醒”
• 是普通 Wake、DarkWake 还是 Maintenance Sleep
• Network、HID、XDCI 等字段应该怎么理解
• 修复后如何通过长时间睡眠记录验证结果

1. 基础命令：查看最近的睡眠 / 唤醒记录

首先可以直接查看最近的睡眠相关日志：

pmset -g log | grep -iE "Sleep|Wake|DarkWake|Wake reason" | tail -100

这条命令适合快速查看最近的：

• Sleep
• Wake
• DarkWake
• Wake reason
• Wake Requests

注意

grep -iE "Sleep|Wake..." 有时会把大量包含 Sleep 字样的 Assertions 也筛出来，例如：

Created SystemIsActive ...
PreventUserIdleSystemSleep ...
InternalPreventDisplaySleep ...

如果输出太杂，不方便分析，就继续使用下面更精确的筛选方式。

2. 精确过滤真正的 Sleep / Wake / DarkWake

推荐使用：

pmset -g log | awk '$4=="Sleep" || $4=="Wake" || $4=="DarkWake" {print}' | tail -80

这样会过滤掉绝大部分无关的 Assertions，主要保留真正的：

Sleep
Wake
DarkWake

对于判断“是否秒醒”“谁触发了唤醒”非常实用。

3. 只查看指定时间段的睡眠日志

排查时不建议把几天甚至几周的历史记录混在一起。

本次实际排查中，只分析：

2026-09-05 23:52
到
2026-09-06 当前时间

使用的命令是：

pmset -g log | awk '($1=="2026-09-05" && $2>="23:52:00") || $1=="2026-09-06"' | awk '$4=="Sleep" || $4=="Wake" || $4=="DarkWake" {print}'

这样可以只看“修复之后”的睡眠表现，避免旧日志干扰判断。

通用写法

例如只想查看某一天：

pmset -g log | awk '$1=="2026-09-06"' | awk '$4=="Sleep" || $4=="Wake" || $4=="DarkWake" {print}'

如果要查看跨两天的指定时间段，可以按上面的方式修改日期和时间。

4. 日志字段怎么读

4.1 正常进入睡眠

典型日志：

Sleep
Entering Sleep state due to 'Software Sleep pid=...'

说明 macOS 已经开始进入睡眠。

例如：

2026-09-06 02:01:33 +0800 Sleep
Entering Sleep state due to 'Software Sleep pid=20990':TCPKeepAlive=disabled Using AC (Charge:0%) 21547 secs

其中：

21547 secs

表示这一次睡眠持续了约：

5 小时 59 分钟

这类长时间记录非常重要，可以证明机器并不是“假睡”或“刚睡下就醒”。

4.2 DarkWake

典型日志：

DarkWake from Normal Sleep

DarkWake 并不等于故障。

macOS 可能在正常睡眠期间短暂唤醒部分硬件，用于：

• 网络维护
• iCloud
• Power Nap / 后台任务
• 定时任务
• 系统维护
• 蓝牙 / Continuity
• 设备状态检查

如果 DarkWake 后没有进入完整桌面，而是重新睡回去，通常属于正常行为。

4.3 Full Wake

典型日志：

Wake from Normal Sleep

或者：

DarkWake to FullWake from Normal Sleep

这代表机器从睡眠状态真正进入完整唤醒。

需要重点看后面的：

due to ...

5. 本次实际排查案例

阶段一：刚睡下十几秒就发生 Network DarkWake

早期日志：

2026-09-06 01:44:13 +0800 Sleep
Entering Sleep state due to 'Software Sleep pid=181':TCPKeepAlive=active Using AC (Charge:0%) 14 secs

仅约 14 秒后：

2026-09-06 01:44:27 +0800 DarkWake
DarkWake from Normal Sleep [CDNP] :
due to PEG1 PEGP PEG2 PEGP RP01 PXSX RP02 PXSX PXSX RP04 PXSX
RP05 PXSX RP06 PXSX RP07 PXSX PXSX RP10 PXSX RP11 PXSX
RP12 PXSX RP13 P/Network
Using AC (Charge:0%) 9 secs

随后：

2026-09-06 01:44:36 +0800 Wake
DarkWake to FullWake from Normal Sleep [CDNVA] :
due to HID Activity
Using AC (Charge:0%) 8 secs

这一组日志说明什么

关键点有两个：

TCPKeepAlive=active

以及：

/Network

说明这一次 Sleep 很快被网络相关 DarkWake 打断。

随后：

due to HID Activity

又把 DarkWake 转成了 Full Wake。

阶段二：类似现象重复出现

后续又出现了多次相同模式：

2026-09-06 01:45:12 +0800 Sleep
Entering Sleep state due to 'Software Sleep pid=181':TCPKeepAlive=active ... 15 secs

随后：

2026-09-06 01:45:27 +0800 DarkWake
... /Network ...

再随后：

2026-09-06 01:45:34 +0800 Wake
DarkWake to FullWake from Normal Sleep ...
due to HID Activity

01:51 和 01:54 左右也出现过类似行为。

这说明：

如果每次睡眠后十几秒就出现 /Network DarkWake，并且随后又转成 Full Wake，那么应该优先排查网络唤醒、TCPKeepAlive、Wake on LAN、Power Nap、相关网卡 / PCIe 唤醒路径等因素。

6. 排查动作：临时关闭可能引发网络 / 后台唤醒的电源管理参数

在本次案例中，异常日志的共同特征是：

TCPKeepAlive=active
...
DarkWake ... due to ... /Network

因此排查时先把几项最容易参与睡眠期间网络维护、后台任务和网络唤醒的 pmset 参数设为 0，尽量减少变量。

这里的目的不是说这四项在所有黑苹果上都必须永久关闭，而是先做排障：如果关闭后“十几秒 Network DarkWake”消失，就说明问题方向基本锁定在睡眠期间的网络 / 后台唤醒链路。

6.1 关闭 TCPKeepAlive

sudo pmset -a tcpkeepalive 0

作用：关闭 macOS 在睡眠期间为了维持部分网络连接而使用的 TCP Keep Alive。

排查价值：本案例异常阶段日志一直显示：

TCPKeepAlive=active

并且很快出现 /Network DarkWake。关闭后，后续睡眠日志变成：

TCPKeepAlive=disabled

这是本次日志中最明显的前后变化之一。关闭该功能后，部分依赖“睡眠期间仍保持网络活动”的服务可能不会继续工作。

6.2 关闭 Power Nap

sudo pmset -a powernap 0

作用：关闭 Power Nap，减少 macOS 在睡眠期间为了 iCloud、邮件、系统维护等后台任务而进入 DarkWake 的机会。

排查价值：如果机器可以正常睡下，但隔一小段时间就因为后台维护进入 DarkWake，关闭 Power Nap 是非常常见的 A/B 测试手段。

6.3 关闭 Proximity Wake

sudo pmset -a proximitywake 0

作用：关闭基于附近 Apple 设备 / 连续互通活动触发的接近唤醒机制。

排查价值：黑苹果使用原生 Broadcom Wi-Fi / 蓝牙、Handoff、AirDrop 等连续互通功能时，如果睡眠阶段存在异常唤醒，可以先暂时关闭 Proximity Wake，排除附近设备和连续互通链路的影响。

关闭它不会等同于关闭 Wi-Fi、蓝牙、AirDrop 或 Handoff 本身，主要影响的是“睡眠期间因为接近 / 连续互通活动而唤醒”这一类行为。

6.4 关闭 Wake on LAN（WOMP）

sudo pmset -a womp 0

作用：关闭 Wake on Magic Packet，即通过网卡收到特定网络唤醒包后唤醒电脑的功能。

排查价值：日志如果出现 /Network、PCIe 网卡路径、网络维护唤醒等现象，临时关闭 WOMP 可以排除“局域网流量 / Magic Packet / 网卡唤醒”这一条路径。

注意：如果这台机器平时需要通过 Wake on LAN 远程开机或远程唤醒，关闭 womp 后这项能力会失效。

6.5 可以一次性执行

如果已经确定要一次性排除以上四类因素，也可以合并成一条命令：

sudo pmset -a tcpkeepalive 0 powernap 0 proximitywake 0 womp 0

其中：

-a

表示对所有供电模式应用设置。对于普通黑苹果台式机，实际通常主要就是 AC Power。

执行后建议立即检查：

pmset -g | grep -E 'tcpkeepalive|powernap|proximitywake|womp'

预期可以看到相应参数为：

tcpkeepalive         0
powernap             0
proximitywake        0
womp                 0

然后重新进行一次睡眠测试，再用前面的日志命令对比修改前后的 Sleep / DarkWake / Wake 时间线。

不建议一看到睡眠异常就把 standby、hibernatemode、autopoweroff 等所有参数全部改成 0。本案例首先根据日志中的 TCPKeepAlive=active 和 /Network 来针对网络 / 后台唤醒做排查，这样更容易判断修改是否真正有效。

7. 关键转折：TCPKeepAlive 变成 disabled

后面的日志出现了明显变化：

2026-09-06 01:57:25 +0800 Sleep
Entering Sleep state due to 'Software Sleep pid=20880':
TCPKeepAlive=disabled
Using AC (Charge:0%) 70 secs

随后虽然还有一次：

2026-09-06 01:58:35 +0800 Wake
Wake from Normal Sleep [CDNVA] :
due to XDCI/HID Activity

但之后出现了真正的长时间睡眠。

8. 修复后的关键验证：连续睡眠约 6 小时

最有价值的一段日志：

2026-09-06 02:01:33 +0800 Sleep
Entering Sleep state due to 'Software Sleep pid=20990':
TCPKeepAlive=disabled
Using AC (Charge:0%) 21547 secs

直到：

2026-09-06 08:00:40 +0800 Wake
Wake from Normal Sleep [CDNVA] :
due to XDCI/UserActivity Assertion
Using AC (Charge:0%)

睡眠持续：

21547 秒

约等于：

5 小时 59 分钟

判断

这一条基本可以证明：

• 机器已经能够正常进入睡眠
• 不存在“几十秒必醒”
• 睡眠状态能够维持数小时
• Normal Sleep 本身已经可以稳定工作

9. DarkWake 后重新进入睡眠：属于正常表现

之后还有一次很有代表性的记录：

2026-09-06 09:28:30 +0800 Sleep
Entering Sleep state due to 'Software Sleep pid=181':
TCPKeepAlive=disabled
Using AC (Charge:0%) 483 secs

约 8 分钟后：

2026-09-06 09:36:33 +0800 DarkWake
DarkWake from Normal Sleep [CDN] :
due to XDCI/
Using AC (Charge:0%) 45 secs

然后：

2026-09-06 09:37:18 +0800 Sleep
Entering Sleep state due to 'Maintenance Sleep':
TCPKeepAlive=disabled
Using AC (Charge:0%) 13402 secs

最后：

2026-09-06 13:20:40 +0800 Wake
Wake from Normal Sleep [CDNVA] :
due to XDCI/HID Activity
Using AC (Charge:0%)

这里的重点是：

DarkWake
↓
45 秒
↓
Maintenance Sleep
↓
重新进入长时间睡眠

这并不是典型故障。

macOS 在后台维护后能够自动重新进入 Sleep，说明睡眠状态机本身工作正常。

10. 常见 Wake Reason 怎么理解

Network

例如：

due to ... /Network

通常优先排查：

• TCPKeepAlive
• Wake on LAN
• Power Nap
• 网卡
• 网络后台维护
• mDNS / Continuity
• PCIe 网卡对应的 ACPI Wake

如果表现为：

Sleep
↓
10～20 秒
↓
/Network DarkWake

非常值得重点关注。

HID Activity

例如：

due to HID Activity

通常表示 Human Interface Device 活动，例如：

• 鼠标
• 键盘
• USB HID
• 蓝牙键鼠
• 某些 USB 接收器

如果本来就是自己碰了鼠标或键盘唤醒，这条属于正常现象。

XDCI

例如：

due to XDCI/HID Activity

或者：

due to XDCI/UserActivity Assertion

不要仅凭 XDCI 就判断 USB 配置一定有问题。

需要结合后面的字段看：

HID Activity
UserActivity Assertion

如果对应的是人为唤醒，就可能完全正常。

只有在：

无人操作
+
频繁 XDCI 自动 Full Wake

的情况下，才值得继续排查 USB Map、XDCI、蓝牙 USB、USB HID、Wake 属性等。

11. Wake Requests 不等于真正的 Wake Reason

日志中经常会看到：

Wake Requests
[process=dasd ...]
[process=mDNSResponder ...]
[process=NotificationCenter ...]
[process=powerd ...]

例如：

process=dasd request=TimerPlugin
info="com.apple.photoanalysisd.internal"

或者：

process=mDNSResponder request=Maintenance
info="upkeep wake"

这些表示：

某个系统进程预约了未来的维护唤醒时间。

它们不一定真的导致了最终 Full Wake。

真正判断机器为什么醒，仍然应该优先看：

Wake from Normal Sleep ... due to ...

或者：

DarkWake from Normal Sleep ... due to ...

12. 不要把 Assertions 当作 Wake Reason

pmset -g log 中还会看到大量：

Assertions
Created SystemIsActive
Released SystemIsActive
PreventUserIdleSystemSleep
InternalPreventDisplaySleep

例如：

cloudd
CloudTelemetryService
sharingd
useractivityd
coreaudiod

这些很多都是机器已经醒来之后产生的活动。

不能看到：

cloudd
CloudTelemetryService
Handoff

就直接认定它们是“唤醒源”。

判断 Wake Source 还是要结合真正的：

Sleep
DarkWake
Wake

时间线。

13. 一个简单实用的排查思路

可以按下面顺序判断：

先执行 pmset -g log
        ↓
只保留 Sleep / Wake / DarkWake
        ↓
找到一次 Entering Sleep
        ↓
看多久后发生下一次 DarkWake / Wake
        ↓
如果只有 10～30 秒
        ↓
看 due to 后面是什么
        ↓
Network / HID / XDCI / RTC / PCIe ...
        ↓
针对对应方向处理
        ↓
再次睡眠
        ↓
观察是否能维持数小时

最终验证标准不是：

日志里完全没有 DarkWake

而应该是：

能够正常进入 Sleep
+
不存在无故反复 Full Wake
+
DarkWake 后能自动重新睡眠
+
可以维持数小时正常睡眠
+
人为唤醒正常

14. 本案例最终结果

本次修复后的实际表现：

02:01:33
进入 Sleep
↓
持续约 5 小时 59 分钟
↓
08:00:40 Wake

随后：

09:28 Sleep
↓
09:36 XDCI DarkWake
↓
45 秒后台活动
↓
09:37 Maintenance Sleep
↓
继续睡约 3 小时 43 分钟
↓
13:20 Wake

因此可以判断：

正常进入睡眠           
长时间维持睡眠         
DarkWake 后重新睡眠    
此前 Network 秒醒消失  
唤醒后系统正常         

注：仅凭日志可以确认“现象发生了变化”，但如果排查过程中同时改动过多个设置，不能只靠这一份日志断言到底是哪一个设置单独造成了修复。最好采用一次只改一个变量的 A/B 测试。

15. 推荐保存的几个排查命令

快速查看最近睡眠相关日志

pmset -g log | grep -iE "Sleep|Wake|DarkWake|Wake reason" | tail -100

精确查看 Sleep / Wake / DarkWake

pmset -g log | awk '$4=="Sleep" || $4=="Wake" || $4=="DarkWake" {print}' | tail -80

查看某一天

pmset -g log | awk '$1=="2026-09-06"' | awk '$4=="Sleep" || $4=="Wake" || $4=="DarkWake" {print}'

查看指定跨日时间段

pmset -g log | awk '($1=="2026-09-05" && $2>="23:52:00") || $1=="2026-09-06"' | awk '$4=="Sleep" || $4=="Wake" || $4=="DarkWake" {print}'

查看当前电源管理设置

pmset -g

查看当前阻止睡眠的 Assertions

pmset -g assertions

结语

黑苹果睡眠排查最重要的不是看到某一个 Wake reason 就立即修改 EFI，而是先建立完整时间线：

什么时候睡
→ 睡了多久
→ 是 DarkWake 还是 Full Wake
→ 谁触发
→ DarkWake 后是否重新睡回去

只要机器能够：

稳定进入 Sleep
+
维持数小时
+
后台 DarkWake 后重新进入 Sleep
+
人为唤醒正常

通常就可以认为睡眠已经基本正常。

尤其要避免把正常的 DarkWake、Wake Requests、Assertions 全部当成故障，否则很容易越调越乱。