setclipboardviewer用于将窗口加入剪贴板查看器链以监听变化，需配合处理wm_drawclipboard和wm_changecbchain消息，并手动转发消息、维护链表、退出时调用changeclipboardchain。
Windows平台用 SetClipboardViewer 监听剪贴板变化
Windows原生不提供“剪贴板内容变更事件”，但可通过消息机制间接实现：让一个窗口成为剪贴板查看器链（clipboard viewer chain）的首节点，系统会在剪贴板内容变更时向该窗口发送 WM_DRAWCLIPBOARD 消息。
关键点在于：SetClipboardViewer 必须由一个**已创建且可见的窗口句柄**调用；它不是全局钩子，也不需要管理员权限；但必须手动维护查看器链（转发消息给下一个查看器），否则其他程序的监听会失效。
- 调用前确保窗口已通过
CreateWindowEx创建并完成ShowWindow/UpdateWindow - 在窗口过程（
WndProc）中处理WM_DRAWCLIPBOARD：此时可安全调用OpenClipboard→GetClipboardData→ 解析内容 - 务必在
WM_CHANGECBCHAIN中更新链表指针——旧的下一节点失效时要跳过它，否则消息中断 - 程序退出前调用
ChangeClipboardChain从链中移除自己，避免句柄悬空导致后续崩溃
读取剪贴板文本时为什么常得到空或乱码
常见错误是没检查格式、没正确转换编码。Windows剪贴板可能同时存在多种格式（CF_TEXT、CF_UNICODETEXT、CF_OEMTEXT），而 GetClipboardData 返回的是原始内存块，不自动解码。
- 优先尝试
CF_UNICODETEXT：返回wchar_t*，可用WideCharToMultiByte(CP_UTF8, ...)转为UTF-8字符串 -
CF_TEXT是ANSI编码，依赖当前系统代码页（如中文Windows是GBK），直接当UTF-8解析必然乱码 - 调用
GlobalLock后记得GlobalUnlock；未解锁就重复读取可能返回NULL - 某些应用（如VS Code、Chrome）写入剪贴板时只放
CF_UNICODETEXT，忽略CF_TEXT，只查后者会漏内容
C++跨平台方案为什么基本不可行
macOS 和 Linux 没有等效于 Windows 剪贴板查看器链的内核级通知机制。所有“跨平台库”（如 clipbrd、cpp-clipboard）本质都是轮询：定期调用 GetClipboardData（Windows）、pbpaste（macOS）、xclip -o（X11）对比哈希值。
- 轮询间隔低于 200ms 容易吃 CPU；高于 1s 可能错过快速粘贴操作
- macOS 的
NSPasteboard支持addObserver:forTypes:，但仅限 Cocoa 应用，纯 C++ 程序需嵌入 Objective-C 混合编译 - Wayland 协议下，客户端无法直接监听系统剪贴板——必须通过 D-Bus 或 wlroots 扩展，且依赖 compositor 实现（如 Hyprland 支持，GNOME 默认不开放）
- 所以所谓“跨平台剪贴板监听”实际是妥协方案：Windows 用消息，其他平台靠轮询+特定API兜底
为什么监听到变化后仍读不到新内容
典型现象：收到 WM_DRAWCLIPBOARD，但紧接着 OpenClipboard 失败，或 GetClipboardData 返回 NULL。根本原因是剪贴板被其他线程/进程短暂独占。
- 不要假设消息到达时剪贴板一定可打开——必须检查
OpenClipboard(hWnd)返回值，失败则稍后重试（最多 3 次，每次WaitForSingleObject50ms） - 某些安全软件（如 Bitdefender）或远程桌面工具（如 AnyDesk）会劫持剪贴板句柄，导致
OpenClipboard阻塞数秒 - 如果目标格式是
CF_HTML或自定义格式（如 VS Code 的MSDEV_ExternalPaste），需先用EnumClipboardFormats枚举确认存在，再读取 - 多线程环境下，绝不能在非 UI 线程调用剪贴板 API——Windows 剪贴板是线程关联的，必须切回创建窗口的线程执行
最麻烦的不是监听不到，而是监听到了却因竞态条件读不到内容。这部分逻辑必须带重试、超时和格式探测，不能只写一次 OpenClipboard 就往下走。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
