windows的systemparametersinfo(spi_getdeskcolor)返回的是经典主题下的桌面颜色而非壁纸主色；准确获取需先定位壁纸路径，再解码图像并提取主色调。
Windows 上用 SystemParametersInfo 读取桌面背景色不靠谱
直接调 SystemParametersInfo 带 SPI_GETDESKCOLOR 参数，返回的其实是旧式“桌面颜色”（即经典主题下右键→属性→外观里的“背景”色），不是当前壁纸的实际主色调。现代 Windows（Win10/11）默认启用动态壁纸、亚克力效果、深色/浅色模式自动切换，这个 API 完全不反映真实背景色。
真正能拿到壁纸主色的路径是：先通过 IKnownFolderManager 或注册表定位壁纸路径 → 用图像解码库（如 stb_image、libpng）加载 → 提取 dominant color（常用中位切分或 K-means）。但注意：HKEY_CURRENT_USERControl PanelDesktopWallpaper 注册表项只存路径，不存颜色；且锁屏壁纸和桌面壁纸可能不同，Wallpaper 键只对应桌面。
- 如果壁纸是纯色（.jpg/.png 单色填充），加载后取中心像素或平均像素即可，快且准
- 如果是风景图，建议采样 200×200 缩略图后做 HSV 聚类，避免被边框/状态栏干扰
- 别用 GDI+ 的
LoadImage+GetPixel，性能差、不支持 WebP、在高 DPI 下易错位
macos 上必须走 NSWorkspace + 图像分析，系统不提供现成颜色 API
macOS 没有类似 Windows 的“桌面色”系统调用。[[NSWorkspace sharedWorkspace] desktopImageURLForScreen:] 只能拿到当前屏幕壁纸 URL，且仅在用户未启用动态桌面（Dynamic Desktop）时可靠；一旦启用了 .heic 动态壁纸或 macOS Ventura 后的实况照片，该 URL 会失效或返回空。
实操上只能：拿到 URL → 用 CGImageSourceCreateWithURL 加载 → 转为 CGImageRef → 提取 bitmap 数据 → 算 dominant color。注意两点：
立即学习“C++免费学习笔记（深入）”；
- macOS 默认对壁纸做模糊/暗化处理（尤其深色模式下），直接读原图会偏亮，建议先模拟系统渲染逻辑：裁切到屏幕尺寸、应用
kCGImageAlphaPremultipliedFirst、再降采样 - 如果壁纸是 icloud 同步的，URL 可能是
file://本地路径，也可能是assets-library://，后者需用PHAsset+PHImageManager异步获取，不能直接 fopen
linux 桌面环境碎片化，得按 DBus 接口逐个适配
Linux 没统一壁纸服务。GNOME、KDE、XFCE、DDE 各自暴露不同 DBus 接口，且同一桌面不同版本参数名还可能变。比如 GNOME 42+ 用 org.gnome.desktop.background 的 picture-uri，而 KDE Plasma 6 改用 org.kde.plasma.desktop 的 Wallpaper 方法，返回结构体而非字符串。
最稳的做法是：先查 DESKTOP_SESSION 或 XDG_CURRENT_DESKTOP 环境变量 → 匹配已知桌面 → 发 DBus 请求 → 下载/读取文件 → 解码取色。别依赖 gsettings get org.gnome.desktop.background picture-uri 这种 shell 命令封装，它在 Wayland 会失败，且不处理缩放路径（如 file:///home/u/.local/share/backgrounds/xxx@2x.jpg）。
- GNOME：DBus 接口稳定，但 URI 可能含
Resource://（内建壁纸），需用GResource解包 - KDE：
Wallpaper方法返回的QVariantMap里可能含多个屏幕的 wallpaper 路径，要按当前屏幕索引取 - 没匹配到桌面？退到 X11 的
_NET_WM_BACKGROUND_PIXMAP属性，但它只存 pixmap ID，无法反查颜色
c++ 跨平台封装时，图像解码必须自己带，别依赖系统 codec
Windows 的 WIC、macOS 的 ImageIO、Linux 的 gdk-pixbuf 都不保证支持同一批格式（比如 WebP 在旧版 macOS 不可用，WIC 在 Win7 默认禁用），且返回的 pixel layout（RGBA vs BGRA vs premultiplied）不一致。用系统解码器，跨平台 color 计算结果必然漂移。
推荐嵌入 stb_image（单头文件、支持 JPG/PNG/GIF/BMP/TGA/PSD/HDRI/WebP）或 libspng（更安全的 PNG 解析）。加载后统一转为 RGBA8888 内存布局，再做后续计算。关键点：
- WebP 解码需显式开启
STB_IMAGE_IMPLEMENTATION和STBI_NO_STDIO，否则在 macOS 上可能因符号冲突崩溃 - Linux 下若用
dlopen加载 gdk-pixbuf，版本号必须硬编码（如"libgdk_pixbuf-2.0.so.0"），不同发行版 soname 不同 - 别在主线程解大图（>5MB），macOS 会卡 ui，Windows 可能触发 DWM 重绘超时，Linux 则可能被 Wayland compositor 杀掉
实际颜色提取算法本身不难，难的是每一步输入都不可信——路径可能无效、图像可能损坏、alpha 通道可能被忽略、显示器色彩空间可能未校准。真正在意准确性的场景，最后还得让用户手动点选校准色块。