windows需消息循环或隐藏窗口才能openclipboard，macos必须主线程且用objective-c++调nspasteboard，linux推荐xclip/xsel而非x11；跨平台应统一错误枚举并用std::optional区分空剪贴板与失败。
Windows平台下用OpenClipboard读取剪贴板内容要先确保线程有消息循环
直接调用OpenClipboard失败（返回false）是常见问题，根本原因是Windows要求调用线程必须处于“可接收消息”状态——也就是得有消息泵（message loop），哪怕只是最简的PeekMessage轮询。控制台程序默认没有，所以常卡在OpenClipboard(NULL)这一步。
- 解决方案：在调用前用
SetThreadDesktop+OpenInputDesktop尝试切换到默认桌面（仅限交互式会话），或更稳妥地——用CreateWindowEx创建一个隐藏窗口并运行简易消息循环 - 注意
CF_UNICODETEXT是安全首选，CF_TEXT可能因编码丢失中文；读取前务必用IsClipboardFormatAvailable检查格式是否就绪 - 别忘了
GlobalLock后要配对GlobalUnlock，否则内存泄漏；CloseClipboard必须在所有操作完成后调用，且不能在GlobalLock期间调用
macOS用NSPasteboard时需链接AppKit且只能在主线程执行
macOS不允许后台线程直接访问剪贴板，[NSPasteboard generalPasteboard]在非主线程调用会静默失败或崩溃。而且C++项目若不带Objective-C桥接，无法直接使用NSPasteboard——必须通过.mm文件或封装成C接口暴露。
- 编译时加
-framework AppKit，链接器不能漏掉；Xcode工程需将对应文件设为Objective-C++（扩展名.mm） - 读取文本用
[pb stringForType:NSPasteboardTypeString]，但要注意返回的是NSString*，需转std::string或std::u16string（用[str UTF8String]或[str length]+[str getCharacters:range:]） - 如果剪贴板里是富文本或图片，
NSPasteboardTypeString查不到内容，得先用types属性枚举可用类型再针对性读取
Linux上xclip或xsel命令行工具比X11原生API更可靠
X11的XOpenDisplay + XConvertSelection流程太重，涉及事件循环、原子查找、多次往返，容易卡死或超时。实际项目中，调用xclip -o -t text/plain或xsel --output --clipboard更简单稳定，前提是系统已安装。
- 用
popen执行命令时，必须设置LC_ALL=C环境变量，避免locale导致输出乱码（尤其中文） -
xclip默认只支持text/plain，读取HTML或图像需显式指定-t参数（如xclip -o -t text/html）；xsel不支持自定义类型，但对纯文本兼容性更好 - 记得检查
pclose返回值和子进程退出码，xclip在剪贴板为空时可能返回非零码而非空输出
跨平台封装时如何统一返回值和错误处理
三个平台返回的数据类型、编码、空值表示方式完全不同：Windows给宽字符指针，macOS给NSString*，Linux给UTF-8字节流。强行统一成std::string会丢信息（如macOS的emoji、Linux的换行符差异）；全用std::u16string又让Linux端多一次转换。
- 建议接口返回
std::optional<:u8string></:u8string>（C++20）或std::pair<bool std::string></bool>，明确区分“读取失败”和“剪贴板为空” - 错误码不要用平台原生值（如Windows的
GetLastError()、macOS的NSError），统一映射为枚举：kNoClipboardAccess、kEmptyClipboard、kUnsupportedFormat - Linux下若检测不到
xclip或xsel，不要静默失败——应返回明确错误，而不是降级到X11 API（复杂度陡增且可靠性低）
真正麻烦的不是读取动作本身，而是各平台对“剪贴板所有权”“格式协商”“线程模型”的隐含约束。写一次封装容易，但让readText()在任意线程、任意桌面环境下都行为一致，得在每个平台补足那些文档里不会写的上下文条件。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
