Clipboard.GetText() 返回空字符串主因是线程未标记[STAThread]，控制台程序需在Main方法添加；跨进程读取受系统隐私设置限制，需手动开启权限；写入失败多因格式不匹配或未指定TextDataFormat.Text。
Clipboard.GetText() 返回空字符串怎么办
多数时候不是代码写错了，而是当前线程没开启消息泵（即没标记 [STAThread]）。WinForms/WPF 应用默认满足，但控制台程序、后台线程或 .NET 6+ 的默认控制台模板会跑在 MTA 线程上，直接调用 Clipboard.GetText() 就静默失败，返回空串。
- 控制台程序必须加
[STAThread]到Main方法上 - 不能在 Task.Run 或新线程里直接调用，得用
Dispatcher.Invoke（WPF）或Control.Invoke（WinForms）切回 UI 线程 - .NET 5+ 控制台项目若启用了
<DisableRuntimeDependencyResolution>true</DisableRuntimeDependencyResolution>，可能缺失 COM 互操作支持，需确认引用了System.Windows.Forms并实际加载了 WinForms 程序集
Clipboard.SetText() 写入后其他程序读不到
常见于未指定文本格式，或目标程序只认特定格式（比如旧版 Notepad 只识别 Text，不认 UnicodeText）。.NET 的 Clipboard.SetText() 默认用 TextDataFormat.UnicodeText，多数现代程序没问题，但某些老旧工具或自定义剪贴板监听器会跳过它。
- 明确指定格式：用
Clipboard.SetText("hello", TextDataFormat.Text)兼容性更好 - 避免传 null 或空字符串——
Clipboard.SetText(null)不清空剪贴板，也不报错，只是什么也不做 - 如果写入的是富文本或图像，务必用对应格式（如
TextDataFormat.Rtf、DataFormats.Bitmap），否则目标程序无法解析
跨进程读写剪贴板时被系统拦截（Windows 10/11）
从 Windows 10 1809 开始，系统默认禁止非前台应用读取剪贴板（防隐私泄露），表现为 Clipboard.GetText() 抛出 InvalidOperationException，错误信息是 "OpenClipboard failed (Exception from HRESULT: 0x800401D0 (CLIPBRD_E_CANT_OPEN))"。
- 用户需手动在「设置 → 隐私 → 剪贴板」中打开「允许应用访问剪贴板」
- UWP 应用或沙盒环境（如 Windows Sandbox）默认无权访问，C# 桌面程序不受此限，但若以低完整性级别运行（如被组策略限制），也会失败
- 没有 API 能绕过该开关——这是系统级拦截，不是 .NET 层可处理的异常
Clipboard.Clear() 清不干净的几种情况
Clipboard.Clear() 只清本进程注册的格式数据，不影响其他进程已写入的内容。更关键的是：它不触发系统级剪贴板清空通知，某些剪贴板管理工具（如 Ditto、ClipX）或浏览器扩展会缓存历史，看起来“没清掉”。
- 真正清空需配合
Clipboard.SetDataObject(new DataObject(), true)，第二个参数true表示“清空后不保留所有权”，强制释放 - 如果之前用
SetDataObject传入了自定义对象且未实现IDisposable，资源可能泄漏，后续GetText()会卡住或抛异常 - 频繁调用
Clear()+SetText()在高频率场景（如实时同步）下可能触发系统节流，建议合并操作
剪贴板本质是全局共享资源，所有操作都依赖 Windows 原生 API 和线程模型约束，绕不开 STAThread、权限开关和格式兼容这三道坎。漏掉任意一个，表现就可能是“没反应”“读出来是空”或者“别人看不见”。
