openclipboard失败应检查调用线程是否拥有hwnd、避免在dllmain中调用、对占用情况加重试；setclipboarddata崩溃因未用gmem_moveable分配内存或提前globalfree；乱码源于ansi/unicode格式不匹配，需统一cf_text/cf_unicodetext；监听应使用addclipboardformatlistener而非轮询。
OpenClipboard 失败返回 FALSE 怎么办
多数剪贴板操作卡在第一步，OpenClipboard 返回 FALSE，不是代码写错了，而是调用时机或窗口上下文不对。
- 必须由拥有窗口句柄（
HWND）的线程调用，控制台程序直接调用大概率失败；加一个隐藏窗口或改用GetDesktopWindow()临时绕过 - 不能在 DLL 的
DllMain或静态构造函数里调，此时线程未关联消息队列 - 如果其他程序正占用剪贴板（比如微信正在复制图片），
OpenClipboard会阻塞或失败——加个简单重试逻辑比硬等更实用
SetClipboardData 传入 GlobalAlloc 分配的内存后崩溃
崩溃通常发生在 SetClipboardData 返回后立刻 GlobalFree，或者没按规范设置内存标志位。
- 必须用
GMEM_MOVEABLE（不是GMEM_FIXED）分配内存，否则 Windows 无法重新定位或锁定 -
GlobalLock后写入数据，写完必须GlobalUnlock，但内存本身不能GlobalFree—— Windows 会在剪贴板清空或下次SetClipboardData时自动回收 - 传入
CF_TEXT时，字符串末尾要带\0，且长度按字节算（lstrlenA+ 1），不是字符数
读取剪贴板中文本乱码（显示为方块或问号）
本质是 ANSI 和 Unicode 混用，Windows 剪贴板默认不区分编码，全靠你告诉它你传的是什么格式。
- 用
IsClipboardFormatAvailable(CF_UNICODETEXT)先判断格式是否存在，别只查CF_TEXT - 读取时优先尝试
CF_UNICODETEXT：用GlobalLock得到wchar_t*，直接转std::wstring，避免多字节转换出错 - 如果只写入了
CF_TEXT，又在 UTF-8 环境下读，必然乱码——写入端和读取端格式必须对得上
剪贴板监听（比如检测用户是否复制了新内容）太耗资源
轮询 GetClipboardSequenceNumber 看似简单，但每毫秒调一次等于把 CPU 拖进泥潭。
立即学习“C++免费学习笔记（深入）”；
- 正确做法是用
AddClipboardFormatListener（Vista+），它通过WM_CLIPBOARDUPDATE发送通知，线程不阻塞也不空转 - 注意该 API 要求窗口有句柄且已调用
RegisterClass，控制台程序需创建消息循环或子类化已有窗口 - 监听器注册后，必须处理
WM_DESTROY时调用RemoveClipboardFormatListener，否则窗口销毁后系统仍往无效地址发消息，可能 crash
真正麻烦的从来不是怎么写那几行 API 调用，而是谁来负责释放内存、谁来保证线程安全、以及什么时候该主动放弃剪贴板所有权——这些细节藏在文档角落，但出问题时第一个背锅。
