Windows平台下阻止屏幕休眠的核心是调用SetThreadExecutionState API并周期性刷新租约，常用组合为ES_SYSTEM_REQUIRED | ES_DISPLAY_REQUIRED | ES_CONTINUOUS；需在退出前调用ES_CONTINUOUS恢复默认行为，否则系统可能长期无法休眠。
Windows平台下用SetThreadExecutionState阻止屏幕休眠
在Windows上禁用屏幕保护和显示器休眠，核心不是“关闭屏保程序”，而是告诉系统当前有活跃的用户活动。最直接、稳定的方式是调用SetThreadExecutionState API，并持续维持其状态。
常见错误是只调用一次就以为生效了——它不是开关，而是“租约”：每次调用只延长一段有效期（默认约1分钟），必须周期性刷新或保持ES_CONTINUOUS标志常驻。
-
ES_SYSTEM_REQUIRED | ES_DISPLAY_REQUIRED | ES_CONTINUOUS是最常用组合：防止系统睡眠、显示器关闭、屏保启动 - 不能只传
ES_DISPLAY_REQUIRED——它只防黑屏，不防屏保激活 - 调用后若程序崩溃或提前退出，未重置状态会导致系统长期无法进入休眠（用户可能误以为电脑卡死）
- 建议搭配
SetThreadExecutionState(ES_CONTINUOUS)在退出前恢复默认行为（即仅传ES_CONTINUOUS）
示例片段：
// 启用防休眠 SetThreadExecutionState(ES_SYSTEM_REQUIRED | ES_DISPLAY_REQUIRED | ES_CONTINUOUS); // ...你的主逻辑... // 退出前恢复（可选但推荐） SetThreadExecutionState(ES_CONTINUOUS);
Linux下通过DBUS禁用屏保（GNOME/KDE通用）
Linux没有统一API，主流桌面环境依赖DBUS服务通信。GNOME用org.gnome.ScreenSaver，KDE用org.freedesktop.ScreenSaver，二者接口高度兼容。
立即学习“C++免费学习笔记（深入）”；
关键点在于：必须运行在有DBUS会话上下文的进程中（即从桌面环境启动，而非SSH远程终端直连）。否则dbus_bus_get会失败，返回NULL。
- 先检查
DBUS_SESSION_BUS_ADDRESS环境变量是否非空，否则dbus_bus_get(DBUS_BUS_SESSION, &error)必然失败 - 调用
Inhibit方法需传入应用标识符（如"myapp"）和原因描述（如"video playback"），返回一个cookie用于后续Uninhibit - 频繁调用
Inhibit而未Uninhibit会导致资源泄漏，部分桌面环境限制同时最多2–3个活跃inhibit锁 - 注意DBus消息超时，默认5秒，网络延迟高或桌面卡顿时可能失败，建议加简单重试
macOS用IOPMAssertionCreateWithName临时禁用睡眠
macOS要求显式声明“为何需要阻止睡眠”，且每个assertion必须配对释放。不释放会导致系统长期无法合盖休眠，电池快速耗尽。
错误做法是把assertion句柄存在局部变量里——函数返回即销毁，导致无法释放；正确做法是全局或类成员持有IOPMAssertionID，并在析构/退出时调用IOPMAssertionRelease。
- 类型选
kIOPMAssertionTypePreventUserIdleDisplaySleep：只防屏幕熄灭和屏保，不影响系统级睡眠（如合盖） - 若需完全阻止睡眠（比如视频转码），改用
kIOPMAssertionTypePreventUserIdleSystemSleep，但需用户授权（首次触发会弹系统提示） - assertion名称（第一个参数）不能含空格或特殊字符，建议用
"com.myapp.nosleep"格式 - 返回值为
kIOReturnSuccess才表示成功，其他值（如kIOReturnNoResources）需记录并降级处理
跨平台封装要注意的三个实际坑
写一个disable_screensaver()函数看似简单，实操中容易栽在环境适配上。
- Windows下若程序以服务身份运行（无交互桌面会话），
SetThreadExecutionState无效——此时应改用SetThreadDesktop切换到WinSta0\Default桌面，或直接放弃干预 - Linux下Wayland会话中，传统DBUS屏保接口可能被禁用，需fallback到
xdg-screensaver suspend命令行方式（依赖xdg-utils） - macOS沙盒应用（App Store分发）默认禁止I/O电源管理API，必须在entitlements中显式添加
com.apple.developer.kernel.iokit权限，否则IOPMAssertionCreateWithName静默失败
真正麻烦的从来不是调哪个函数，而是判断当前到底处在哪种会话环境里——GUI进程？systemd service？SSH登录后的X11转发？这些上下文决定了你该走哪条路径，也决定了失败时该怎么降级或报错。
