最可靠方式是调用系统原生api：windows用enumdisplaysettings获取当前整数刷新率，macos用cgdisplaygetrefreshrate获取标称值，linux用xrandr--current或/sys/class/drm/解析；vrr及支持范围需底层edid或drm ioctl解析。
Windows平台用 EnumDisplaySettings 获取当前显示器刷新率
直接调用 Windows API 是最可靠的方式，EnumDisplaySettings 能拿到当前活动显示模式的 dmDisplayFrequency 字段，但它只返回整数赫兹值（如 60、144），不包含小数精度或 VRR 动态范围信息。
实操注意点：
- 必须传入正确的设备名：用
EnumDisplayDevices先枚举出主显示器名称（如"\\.\DISPLAY1"），不能硬编码或用空字符串 - 调用时
dwModeNum应设为ENUM_CURRENT_SETTINGS（即 -1），否则可能读到旧模式或失败 - 返回的
DEVMODE结构中，dmFields需包含DM_DISPLAYFREQUENCY才能信任dmDisplayFrequency值 - 该 API 不支持获取可变刷新率（VRR）的 min/max 范围，它只反映当前生效的固定频率
macOS 上通过 CGDisplayGetRefreshRate 和 IOServiceGetMatchingServices 补充细节
CGDisplayGetRefreshRate 返回的是 double 类型的标称刷新率（例如 59.97），但它是 Core Graphics 层的抽象值，不体现底层 EDID 或 DisplayPort 自适应同步能力。
若需更底层参数（如支持的刷新率列表、VRR 区间），得走 IOKit：
- 用
IOServiceGetMatchingServices查找IODisplayConnect实例 - 从匹配服务中调用
IORegistryEntryCreateCFProperties提取原始 EDID blob - 手动解析 EDID 中的
monitor range limits（字节 0x28–0x2F）和 CVT/DMT 定时描述符 - 注意：EDID 解析无官方 C++ 接口，需自己实现或依赖第三方库（如
libedid）
Linux 下读取 /sys/class/drm/ 和 xrandr --verbose 的差异
Linux 没有统一 API，主流方式是组合使用 sysfs 和 X11/Wayland 工具输出：
-
/sys/class/drm/card0-DP-1/mode文件内容含当前分辨率+刷新率（如"1920x1080@60"），但格式不规范，需正则提取 -
xrandr --verbose输出中每块Monitor:下的Supported monitor frequencies:行才真正列出所有支持的刷新率区间（包括 VRR 的 min/max） - Wayland 环境下
xrandr可能不可用，应改用weston-info或 wlroots 的wlr_output_get_mode（需链接 wlroots 库） - 注意：
/sys/class/drm/下的frequency文件并不存在 —— 这是个常见误解，别白费时间找
跨平台统一获取的现实限制与取舍建议
没有标准 C++ 接口能同时拿到“当前实时刷新率 + 支持范围 + VRR 状态”，因为操作系统抽象层根本没暴露这些信息给用户态程序。
实际项目中建议按需选择：
- 只要当前生效值：Windows 用
EnumDisplaySettings，macOS 用CGDisplayGetRefreshRate，Linux 用xrandr --current解析 - 需要支持范围：Windows 必须遍历
EnumDisplaySettings所有模式；macOS 必须解析 EDID；Linux 必须 parsexrandr --verbose或读取/sys/firmware/acpi/video/（仅限部分笔记本） - VRR 是否启用：Windows 无公开接口；macOS 只能在 Metal 渲染器里通过
MTLCommandBuffer查询；Linux 需检查DRM_IOCTL_MODE_GETCONNECTOR的connector->vrr_capable字段（需 root 权限和 DRM 直接访问）
EDID 解析和 DRM ioctl 是最容易卡住的地方 —— 数据结构杂乱、文档稀少、权限要求高，真要覆盖全场景，得准备好啃几周内核文档和 spec 手册。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
