Windows 无直接查询休眠状态的 API，但可通过 GetThreadExecutionState 检测是否被标记为即将休眠，需先调用 SetThreadExecutionState 设置唤醒锁；Linux 则依赖 systemd D-Bus 的 PrepareForSleep 信号或 systemctl list-jobs 判断，轮询 /sys/power/state 不反映实时状态。
Windows 上用 GetThreadExecutionState 判断系统是否即将休眠
Windows 不提供直接查询“当前是否处于休眠状态”的 API，但能通过 GetThreadExecutionState 检测系统是否被标记为“即将进入睡眠/休眠”——这是最贴近你需求的实用方式。该函数返回当前线程设置的执行状态标志，若不含 ES_CONTINUOUS 或被其他进程清除了保持唤醒的标志，系统就可能在下一秒触发休眠。
- 调用前需确保已用
SetThreadExecutionState(ES_CONTINUOUS | ES_SYSTEM_REQUIRED | ES_AWAYMODE_REQUIRED)主动申请过唤醒锁，否则返回值无参考意义 - 返回值是位掩码，重点看是否包含
ES_SYSTEM_REQUIRED：若不包含，说明系统未被任何进程显式阻止休眠，且电源策略允许时将按计划休眠 - 该函数本身不阻塞，也不触发状态变更，只是快照式读取——不能靠它“监听”休眠事件，只能轮询（建议间隔 ≥1s，避免干扰电源管理）
Linux 下通过 /sys/power/state 和 systemd 接口间接判断
Linux 没有统一的“休眠中”状态标识，但可通过两个层面交叉验证：/sys/power/state 显示当前支持的休眠类型（如 mem、disk），而真正是否正在休眠，得看 systemd 的 inhibit 锁或内核 suspend log。
- 读取
/sys/power/state只反映能力，不是实时状态；若内容为空或只含freeze，说明休眠功能被禁用（如 BIOS 关闭 S3/S4） - 更可靠的方式是检查
systemd-inhibit锁：运行systemctl list-jobs | grep -q 'suspend\|hibernate'，若有匹配 job 正在运行，大概率正处于休眠流程中 - 注意：休眠瞬间内核会冻结所有用户态进程，此时你的 C++ 程序很可能已被挂起，无法主动检测——所以实际场景中，应在 suspend 前通过
systemd的sleep.target或 D-Bus 信号（org.freedesktop.login1.PrepareForSleep）提前获知
跨平台方案本质受限，别试图轮询“休眠中”状态
所谓“当前系统的休眠状态”，在绝大多数操作系统里并不存在一个稳定、可读、实时更新的布尔值。休眠（suspend-to-RAM）和休眠（hibernate-to-disk）都是瞬态过程：从开始到完成通常在 200–800ms 内，中间没有“正在休眠”的公开状态暴露给用户态程序。
- Windows 的
WM_POWERBROADCAST消息（PBT_APMSUSPEND/PBT_APMRESUMEFROMSUSPEND）才是真正的事件入口，比轮询GetThreadExecutionState高效且准确 - Linux 下必须依赖
logindD-Bus 接口，监听PrepareForSleep(true)信号，这是唯一被保证在挂起前发出的通知 - 直接读取
/proc/sys/kernel/power_state或类似路径？不存在——Linux 内核不导出这个信息，第三方 procfs 条目多为伪造或过时
容易忽略的关键点：休眠 ≠ 屏幕关闭，也 ≠ 系统空闲
很多开发者混淆了电源状态层级：屏幕关闭（DPMS）、会话锁定（lock screen）、系统空闲计时器超时、ACPI S3（suspend）、S4（hibernate）是不同机制，彼此可能独立触发。你的程序如果只监控鼠标/键盘事件或 GetLastInputInfo，完全无法反映真实休眠意图。
立即学习“C++免费学习笔记（深入）”；
- Windows 中，即使设置了
ES_DISPLAY_REQUIRED，系统仍可在黑屏后进入 S3，因为显示唤醒锁不影响内存供电 - Linux 上，
systemd-logind默认配置可能允许“空闲 15 分钟后挂起”，但若用户启用了IdleAction=lock，则只会锁屏，不会休眠——需查loginctl show --property=IdleAction - 无论哪个平台，都不要在休眠回调中做耗时操作（如写文件、网络请求），内核要求响应必须在几百毫秒内完成，超时会导致挂起失败或系统卡死
