需调用OpenClipboard(NULL)后枚举CF_HDROP格式确认文件列表存在，再通过GetClipboardData获取HGLOBAL句柄，用GlobalLock锁定后以DragQueryFile安全提取Unicode路径，最后GlobalUnlock并CloseClipboard。
Windows 平台下用 OpenClipboard + EnumClipboardFormats 检查是否含文件列表
系统剪切板里有没有拖入的文件路径，不是靠“读文本”能判断的——得查原生格式。Windows 用 CF_HDROP 格式承载文件列表（比如从资源管理器拖文件到程序），但这个格式不会自动暴露为字符串，必须主动枚举并确认存在。
常见错误是直接调 GetClipboardData(CF_TEXT) 或 GetClipboardData(CF_UNICODETEXT)，结果返回 NULL 还以为没内容；其实只是格式不匹配。
- 必须先调
OpenClipboard(NULL)，否则所有操作失败（且不报错，静默失败） - 接着用
EnumClipboardFormats循环检查，直到返回0，中间遇到CF_HDROP就说明有文件列表 - 别跳过
CloseClipboard()，否则后续其他程序可能卡住剪切板（尤其在调试时反复运行容易触发）
用 GlobalLock + DragQueryFile 提取文件路径数组
确认有 CF_HDROP 后，得拿到句柄再解包。这里最容易踩的坑是：直接对 HGLOBAL 强转指针去解析结构——HDROP 是 Windows 封装类型，内部布局不公开，必须通过 DragQueryFile 安全读取。
使用场景很明确：用户从文件管理器拖了一堆文件到你的窗口，你想知道具体路径做后续处理（比如批量导入）。
- 调
GetClipboardData(CF_HDROP)得到HGLOBAL，再用GlobalLock锁定内存，传给DragQueryFile - 第一次调
DragQueryFile(hdrop, 0xFFFFFFFF, NULL, 0)获取文件总数（注意是0xFFFFFFFF，不是-1） - 第二次起循环调
DragQueryFile(hdrop, i, buf, MAX_PATH)逐个读路径，buf必须是宽字符缓冲区（wchar_t），因为路径可能是 Unicode - 用完记得
GlobalUnlock和CloseClipboard，否则内存泄漏+剪切板锁死
为什么不用 clipboard（C++20）或第三方库？
C++20 的 SDL 或 Qt 的剪切板 API 默认只支持文本，对 CF_HDROP 这类平台专属格式不透明封装。
这意味着：如果你真要读文件列表，绕不开 Windows 原生 API。强行套跨平台抽象，要么功能阉割（只能读文本），要么底层还是得写 Win32 分支代码。
- MSVC 19.3x 及以下版本：
- Qt 的
QClipboard::mimeData()在 Windows 下对CF_HDROP返回空QByteArray，无法还原路径 - 性能上无差异——原生调用就是几层 kernel32 函数，没额外开销
常见错误现象和兼容性注意点
实际跑起来报 NULL、崩溃、或路径乱码，八成是这几个点没对齐：
-
OpenClipboard传了窗口句柄（比如GetForegroundWindow()）但权限不足 → 改用NULL（推荐） - 缓冲区用
char buf[260]接路径 → 必须用wchar_t buf[MAX_PATH]，否则中文路径变问号或截断 - 忘记在
DragQueryFile前调GlobalLock→ 返回长度总是 0 - 在非 UI 线程（比如后台工作线程）调用 → Windows 剪切板 API 要求调用线程有消息循环（
COINIT_APARTMENTTHREADED不够），必须在主线程或显式创建 STA 线程
真正麻烦的从来不是“怎么读”，而是“什么时候能安全读”——比如用户刚松开鼠标，你的窗口还没收到 WM_DROPFILES 消息，就急着去查剪切板，大概率查不到。时机比语法细节更难调试。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
