最有效方式是聚焦关键词、时间范围和系统子模块：用 log show 配合 predicate 筛选 Sleep/Wake/DarkWake 事件，结合 pmset -g assertions 查阻止休眠的进程，并通过 kernel 子系统日志分析 ACPI/PM 状态及硬件唤醒源。
直接用 log show 查电源和睡眠日志，最有效的方式是聚焦关键词、时间范围和系统子模块，而不是翻全量日志。
查最近一次休眠与唤醒全过程
运行这条命令能拉出过去一小时内所有睡眠、唤醒相关记录：
log show --predicate 'eventMessage contains "Sleep" or eventMessage contains "Wake" or eventMessage contains "DarkWake"' --last 1h- 输出里重点关注带 Wake reason: 的行，比如
Wake reason: EC.LidOpen(User)表示开盖唤醒，Wake reason: USB说明有 USB 设备触发了唤醒 - 若看到
Sleep interrupted或反复出现DarkWake → Sleep循环，大概率有进程或硬件在阻止真正进入深度休眠
定位阻止休眠的后台活动
有些程序会主动“锁住”休眠状态，用断言（assertions）机制阻止系统睡眠：
- 执行
pmset -g assertions，看 sleep prevented by 后面列出的进程名（如coreaudiod、backupd、GoogleSoftwareUpdateAgent） - 再配合日志确认：运行
log show --predicate 'eventMessage contains "assertion" and eventMessage contains "prevent"' --last 2h - 常见干扰项包括未关闭的 Time Machine 备份、正在运行的虚拟机、调试工具（如 Xcode）、或某些第三方音视频软件
过滤内核级电源事件（含 ACPI 和硬件唤醒源）
底层电源切换由内核和驱动控制，这类日志集中在 kernel 子系统：
log show --predicate 'subsystem == "com.apple.kernel" and (eventMessage contains "ACPI" or eventMessage contains "PM")' --last 24h- 特别留意含 ACPI S3、ACPI S4、RTC wake、PCI power state 的条目，它们反映硬件是否按预期进入/退出低功耗状态
- 黑苹果用户可在此处发现缺失的 DSDT 补丁效果——例如本该进入 S4（休眠）却只走到 S3（睡眠），说明 hibernatemode 没生效或 HibernationFixup.kext 未正确加载
导出并离线分析关键片段
如果日志量大或需反复比对，建议导出结构化文本：
- 保存最近 12 小时所有电源相关日志：
log show --predicate 'eventMessage contains "Sleep" or eventMessage contains "Wake" or eventMessage contains "hibernate"' --last 12h > ~/Desktop/sleep_log.txt - 加
--style json可导出带时间戳、进程名、子系统的完整结构：log show --predicate 'eventMessage contains "Wake reason"' --last 3h --style json > ~/Desktop/wake_reason.json - 打开文本文件后，用 Cmd+F 搜索 Wake reason、hibernatemode、standbydelay 等关键词，快速定位异常节点
