Windows平台用EnumDisplaySettings查刷新率最可靠，需传ENUM_CURRENT_SETTINGS、初始化DEVMODE.dmSize并检查返回值，dmDisplayFrequency字段即当前生效刷新率（Hz），为0时应视为未知而非硬编码fallback。
Windows平台用EnumDisplaySettings查刷新率
Windows下最直接的方式是调用GDI API的EnumDisplaySettings，它能读取当前活动显示器的当前模式（包括刷新率）。注意：必须传ENUM_CURRENT_SETTINGS，而不是ENUM_REGISTRY_SETTINGS，否则返回的是注册表里存的默认值，不是实时生效的设置。
常见错误是忽略返回值判断——函数失败时会返回false，此时DEVMODE.dmDisplayFrequency不可信。还要注意DEVMODE结构体需初始化dmSize字段，否则调用可能崩溃。
- 使用前用
ZeroMemory(&dm, sizeof(dm))清零整个结构体 -
dm.dmSize = sizeof(dm)必须显式赋值，否则API不识别 - 多显示器场景下，需先用
EnumDisplayDevices枚举设备名，再对每个设备调用EnumDisplaySettings - 返回的
dmDisplayFrequency单位是Hz，但某些老旧驱动可能返回0，这时应 fallback 到1或60
垂直同步状态无法通过系统API直接获取
操作系统本身不暴露“VSync是否开启”这个状态——它属于GPU驱动层控制的渲染行为，应用层无权限读取。所谓“开启垂直同步”，实际是图形API（如OpenGL、DirectX、Vulkan）在创建交换链或设置呈现参数时向驱动发出的请求，驱动是否真正执行、是否被强制覆盖（比如NVIDIA控制面板全局启用/禁用），应用完全不知情。
因此，没有类似IsVSyncEnabled()这样的系统函数。你只能间接推断：
立即学习“C++免费学习笔记（深入）”；
- 若用
wglSwapIntervalEXT(1)或glfwSwapInterval(1)成功调用，说明应用已请求开启，但不保证生效 - 测量连续
SwapBuffers的时间间隔：如果稳定接近1000/refresh_ratems，大概率VSync起效；若波动剧烈，则可能被禁用或驱动绕过 - DirectX中可检查
DXGI_SWAP_CHAIN_DESC1.Scaling和Flags，但仅反映创建时的意图，非运行时状态
跨平台方案只能靠图形API反推
Linux（X11/Wayland）和macOS均无等价于Windows GDI的显示器刷新率查询接口。X11下可通过xrandr --verbose解析输出，但这是命令行工具，C++需popen解析文本，不稳定且依赖环境；Wayland几乎不提供刷新率信息；macOS需用CGDisplayModeGetRefreshRate，但它只对主显示器有效，且返回值常为0（尤其外接显示器）。
更可靠的做法是统一走图形上下文路径：
- OpenGL：用
glfwGetVideoMode(glfwGetPrimaryMonitor())->refreshRate（GLFW封装了各平台逻辑） - Vulkan：需通过
vkGetPhysicalDeviceSurfaceCapabilitiesKHR拿到minImageCount和currentExtent，但刷新率仍需结合vkGetPhysicalDeviceSurfaceFormatsKHR和平台扩展（如VK_KHR_surface不提供频率） - 本质仍是“查显示器能力”，而非“查当前生效频率”——如果用户动态切换了缩放或分辨率，这些值不会自动更新，需重新查询
刷新率跳变时的典型陷阱
现代显示器（尤其支持FreeSync/G-Sync）可能在不同负载下动态调整刷新率，而EnumDisplaySettings这类API只返回当前模式的标称值，无法反映瞬时变化。例如：游戏帧率掉到48fps时，显示器可能从144Hz降到48Hz，但系统API仍报告144Hz。
这意味着任何基于“一次查询就长期缓存”的逻辑都会出错。真实项目中必须：
- 在窗口大小改变、显示器热插拔（
WM_DISPLAYCHANGE）、或每秒定时轮询（如每5秒）时重新调用EnumDisplaySettings - 避免把刷新率硬编码进帧时间计算——应始终用最新值算
deltaTime - 垂直同步开启时，实际帧间隔由显示器决定，而非CPU/GPU计时器，所以
std::chrono测得的间隔可能略大于理论值（因信号传输延迟）
真正难的不是怎么查，而是查完之后如何应对它随时变化。很多性能问题其实源于假设刷新率恒定。
