windows 通过 setthreadexecutionstate 阻止睡眠并结合 wm_powerbroadcast 消息（pbt_apmsuspend/pbt_apmresumeautomatic）感知睡眠/唤醒；linux 推荐监听 systemd 的 prepareforsleep d-bus 信号；macos 使用 ioserviceaddinterestnotification 监听 kiomessagesystemwillsleep/kiomessagesystemhasresumed。
Windows 下用 SetThreadExecutionState 持续保活并间接感知睡眠
Windows 没有直接暴露“系统已进入睡眠”的事件，但能通过阻止睡眠 + 监控执行状态变化来反向推断。核心思路是：调用 SetThreadExecutionState 申请持续唤醒（如 ES_CONTINUOUS | ES_SYSTEM_REQUIRED | ES_DISPLAY_REQUIRED），当该调用突然失效（比如返回 0 且 GetLastError() 为 ERROR_ACCESS_DENIED），往往意味着系统刚从睡眠恢复——因为睡眠期间所有线程挂起，唤醒后原执行状态被重置。
更稳妥的做法是结合 Windows 电源设置通知：RegisterPowerSettingNotification 订阅 GUID_POWER_SETTING_TIMEOUT 或 GUID_CONSOLE_DISPLAY_STATE，但真正能捕获睡眠开始的只有 GUID_POWER_SETTING_TIMEOUT（需配合 WM_POWERBROADCAST 消息监听 PBT_APMPOWERSTATUSCHANGE 和 PBT_APMRESUMEAUTOMATIC）。
- 必须在 GUI 线程中处理
WM_POWERBROADCAST，控制台程序需创建隐藏窗口才能接收 -
PBT_APMSUSPEND消息在睡眠前发出，但不保证有足够时间执行耗时操作（通常只剩几十毫秒） - 不要依赖
GetSystemPowerStatus轮询——它只反映当前 AC/电池状态，无法区分“待机”和“睡眠”
Linux 下读取 /sys/power/state 和监听 systemd 事件
Linux 没有统一 API，但可通过两种可靠方式检测：
一是检查 /sys/power/state 文件内容是否包含 mem（Suspend to RAM）或 disk（hibernate）。该文件在系统准备睡眠前会短暂变为只读，且内核会在写入该文件触发睡眠时同步广播 netlink 事件；二是监听 systemd 的 PrepareForSleep D-Bus 信号（接口 org.freedesktop.login1），这是最常用也最及时的方式。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 使用
dbus-monitor --system "interface='org.freedesktop.login1',member='PrepareForSleep'"可手动验证信号是否发出 - C++ 中需链接
libsystemd并调用sd_bus_add_match，注意信号参数是布尔值：true表示即将睡眠，false表示刚唤醒 - 不要轮询
/proc/sys/dev/pm/suspend_state——该路径在多数发行版中不存在或已废弃
macOS 上监听 IOPMrootDomain 的 kIOMessageSystemWillSleep
macOS 提供 I/O Kit 事件机制，通过注册对 IOPMrootDomain 的通知来捕获睡眠/唤醒事件。关键函数是 IOServiceAddInterestNotification，监听消息类型为 kIOMessageSystemWillSleep（睡眠前）和 kIOMessageSystemHasResumed（唤醒后）。
必须注意：回调函数运行在内核上下文，不能调用大多数用户态 API（如 std::cout、堆分配、锁），只能做轻量标记或发 Mach port 消息到用户进程。
- 注册前需用
IOServiceGetMatchingServices获取IOPMrootDomain的 service handle - 回调中禁止调用
CFRunLoop或任何阻塞操作，否则导致系统卡死或睡眠失败 - 如果进程是 launchd 管理的服务，还需在 plist 中声明
EnableTransactions为true，否则通知可能被丢弃
跨平台方案为何不推荐轮询 GetTickCount64 或时间差
有人试图用两次 GetTickCount64（Windows）或 clock_gettime(CLOCK_MONOTONIC)（Linux/macOS）的时间差突增来判断睡眠——这不可靠。现代系统在睡眠期间仍可能给某些设备供电，计时器未必完全停摆；更常见的是，睡眠唤醒后系统时钟被校准（如 NTP 同步），造成时间跳变，与真实睡眠无关。
- Windows 的
QueryUnbiasedInterruptTime理论上更准确，但它只在较新版本支持，且文档明确说明“不保证连续性”，不能用于差值判断 - macOS 的
mach_absolute_time在深度睡眠（Standby/Suspend to Disk）下也会暂停，但普通 Sleep（S3）下不一定，行为不一致 - 唯一能用时间差辅助判断的场景，是配合其他信号（如收到
PBT_APMSUSPEND后再看时间是否跳变），单独使用毫无意义
真正的难点不在获取事件，而在事件到达时的安全响应：睡眠通知到来时，你可能正持有文件锁、网络连接或 GPU 资源——这些资源在睡眠过程中会被系统回收，唤醒后不重置就容易 crash。这点比“怎么检测”更值得花时间设计。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
