GetPixel虽最直接，但性能差、不推荐高频调用；单次耗时1–5微秒，连续采样易卡顿，且受DPI缩放、多显示器、UAC权限及窗口遮挡限制，仅适合偶尔取色。
Windows平台用GetPixel最直接，但性能差、不推荐高频调用
在Windows上，GetPixel是最容易想到的函数：传入设备上下文（HDC）和坐标，返回COLORREF。但它每次调用都触发GDI系统调用，单次耗时约1–5微秒，连续读取100×100区域可能卡顿明显。
常见错误是直接在窗口OnPaint里反复调用GetPixel做实时采样——画面会掉帧。更糟的是，若用GetDC(NULL)获取全屏DC，还可能因DPI缩放或多显示器导致坐标偏移。
- 必须先调用
GetDC(NULL)获取屏幕DC，用完立刻ReleaseDC(NULL, hdc) - 坐标是屏幕绝对坐标（左上角为
(0, 0)），不是客户区坐标 -
GetPixel返回值需用GetRValue()、GetGValue()、GetBValue()拆解RGB - 高DPI模式下，若未启用进程DPI感知，
GetPixel仍按逻辑像素工作，实际采样位置可能错位
跨平台方案得靠libxdo（Linux）或CGDisplayCreateImage（macOS）
Linux下libxdo提供xdo_get_mouse_location和xdo_get_pixel_color，但需X11环境；Wayland下原生不支持像素读取，多数程序退而求其次用截图+查点（如gnome-screenshot后解析PNG）。
macOS必须用Core Graphics：CGDisplayCreateImage截取整屏再用CGImageGetDataProvider提取像素数据——开销比GetPixel大得多，但稳定。注意CGImage坐标系Y轴朝下，屏幕(0,0)对应图像底部左角。
立即学习“C++免费学习笔记（深入）”；
- Linux：
sudo apt install libxdo-dev，链接-lxdo，调用前确保X server运行 - macOS：需在
Info.plist中声明NSAppleEventsUsageDescription，否则CGDisplayCreateImage返回NULL - 所有跨平台方案都无法绕过“截图→内存解码→取点”流程，单点延迟普遍在5–20ms量级
真正高性能的方案是共享桌面帧缓冲（仅限Windows + DirectX）
如果目标是每秒读取数百次以上（比如录屏分析、眼动追踪辅助），必须绕过GDI。Windows 8+提供Desktop Duplication API，能高效获取帧缓冲指针，再直接按偏移计算像素地址。
这需要创建DirectX设备、获取IDXGIOutputDuplication接口、调用AcquireNextFrame——代码量翻倍，但吞吐量提升百倍。关键点在于：帧数据是BGRA格式、pitch对齐（每行字节数≠宽度×4），且必须ReleaseFrame否则后续调用阻塞。
- 初始化开销大（首次调用约10ms），适合长时运行场景
- 无法获取被遮挡窗口的内容（如全屏游戏独占渲染）
- 多显示器需分别枚举
IDXGIOutput，不能靠全局坐标直接索引 - 返回的
DXGI_OUTDUPL_FRAME_INFO含时间戳，可用于判断是否新帧
别忽略权限和UAC限制：非管理员进程在Win10/11上可能读不到其他应用窗口
从Windows 10 1809起，系统默认阻止低完整性级别进程读取高完整性级别窗口像素（比如普通程序无法采样以管理员身份运行的CMD窗口）。此时GetPixel返回CLR_INVALID，Desktop Duplication则直接失败并报错DXGI_ERROR_ACCESS_DENIED。
用户常以为是代码写错，其实是UAC弹窗没点“是”，或进程manifest未声明requireAdministrator。macOS上同样受限：未开启“屏幕录制”权限的应用，CGDisplayCreateImage始终返回NULL，且无明确错误提示。
- Windows：检查
IsProcessElevated()，失败时引导用户右键→“以管理员身份运行” - macOS：首次调用前先
CGRequestScreenCaptureAccess()，并在设置→隐私→屏幕录制中手动勾选 - Linux：X11下需当前用户拥有
/dev/input/event*读权限（影响鼠标位置获取），但像素读取本身无此限制
GetPixel或CGDisplayCreateImage加缓存就够了。真要压榨性能，别纠结单点API，直接上帧缓冲+SIMD批量处理——但得先确认你真的需要每秒几千次采样。 
