clipboard.getimage() 返回 null 是因仅支持 bitmap 或 deviceindependentbitmap 格式，而微信、qq、win+shift+s 等常使用 enhancedmetafile 或自定义格式；应改用 getdataobject() 检查格式并手动处理。
Clipboard.GetImage() 返回 null 是最常见的失败原因
不是所有图片都能被 Clipboard.GetImage() 正确识别。它只支持 Windows 原生剪贴板中以 Bitmap 或 DeviceIndependentBitmap 格式存放的图像，而截图工具（如 Win+Shift+S）、微信、QQ 复制的图，经常走的是 EnhancedMetafile 或自定义格式，此时 GetImage() 直接返回 null，不报错也不提示。
实操建议：
- 先用
Clipboard.ContainsImage()判断——但它也靠不住，某些含图数据它会返回true，但GetImage()仍为null - 改用
Clipboard.GetDataObject()获取原始数据对象，再手动检查可用格式：dataObject.GetFormats()，重点关注"Bitmap"、"System.Drawing.Bitmap"、"EnhancedMetafile"、"PNG"、"JFIF" - 对
"EnhancedMetafile"，可尝试用Metafile构造并转成Bitmap；对"PNG"或"JFIF"，用MemoryStream+Image.FromStream()
复制 Bitmap 到剪贴板必须用 Clipboard.SetImage()，别用 SetData
Clipboard.SetData() 看似灵活，但传入 Bitmap 对象时，底层可能把它序列化成不可靠的私有格式，导致其他程序（比如 Paint 或微信）无法识别。而 Clipboard.SetImage() 会强制转换为标准 Bitmap 格式，并写入剪贴板的 "Bitmap" 格式槽位，兼容性高得多。
实操建议：
- 确保传入的是
System.Drawing.Bitmap实例，不是Image抽象类或Graphics对象 - 如果图来自文件，用
new Bitmap("path.png")加载后传入；若来自内存流，先Image.FromStream(stream)再转成Bitmap（避免Image被释放后出问题） - 调用前确认线程是 STA 模式（WinForms/WPF 默认满足；控制台程序需在
Main方法上加[STAThread]）
WPF 和 WinForms 的剪贴板行为差异容易被忽略
WPF 的 Clipboard 类其实是对 Win32 API 的封装，而 WinForms 的 Clipboard 更贴近 GDI+ 行为。例如：WPF 下 SetImage() 对 PNG 数据支持更好；WinForms 下直接传 Bitmap 更稳，但对透明通道处理稍弱。
实操建议：
- WPF 项目中，若要保留 Alpha 通道，优先用
Clipboard.SetImage()+RenderTargetBitmap渲染 UIElement，而不是截屏后转Bitmap - WinForms 中，避免用
Graphics.CopyFromScreen()后直接塞进剪贴板——它生成的Bitmap可能不含完整像素信息，建议用Bitmap.Clone()创建新实例再传 - 跨平台需求？别指望 .NET Core/.NET 5+ 的
System.Windows.Forms.Clipboard在 Linux/macOS 生效，它仅限 Windows
图片尺寸过大或 DPI 不匹配会导致粘贴失真
Windows 剪贴板本身不限制大小，但目标应用（如 Word、Outlook、企业微信）可能对图像尺寸、DPI、编码格式有隐式限制。常见现象：原图 4000×3000，粘贴后变成模糊小图，或只显示左上角一块。
实操建议：
- 获取图像后，检查
bitmap.HorizontalResolution和VerticalResolution，非 96 DPI 的图（比如截图工具默认 120/144）建议用Graphics.DrawImage()重绘到新Bitmap并设为 96 DPI - 超大图（>5000px 边长）建议预缩放——不是为了剪贴板，而是防止目标程序崩溃或降质渲染
- 避免在
Clipboard.SetImage()后立刻退出程序，某些系统版本下资源释放过快会导致粘贴内容为空
