为何无法将DIB Section放入Windows剪贴板？

我来帮你拆解这个问题——你遇到的现象其实是Windows剪贴板对不同位图类型的处理逻辑差异导致的，咱们一步步说清楚：

核心原因分析 #

1. 用CF_BITMAP传入DIBSection时的隐藏坑 #

你调用SetClipboardData(CF_BITMAP, hDIBSection)时API返回成功，但剪贴板里看不到图像，大概率是内存所有权和生命周期的问题：

• CF_BITMAP要求传入的HBITMAP是标准GDI对象，且剪贴板会接管这个对象的所有权——也就是说，你不能在调用SetClipboardData后自己调用DeleteObject销毁它，也不能释放DIBSection对应的像素内存块（就是CreateDIBSection返回的lpvBits指针指向的内存）。
• CreateCompatibleBitmap创建的是设备相关位图（DDB），它的内存完全由GDI管理，剪贴板接管后可以直接读取GDI内部的内存，不会依赖你的进程内存。但DIBSection的像素数据是映射在你的进程空间里的，如果你提前释放了这块内存或者进程退出，剪贴板就无法读取到像素数据，自然看不到图像。

2. 用CF_DIB调用失败的直接原因 #

SetClipboardData(CF_DIB, ...)的参数要求是指向BITMAPINFO结构的全局内存指针，而不是HBITMAP句柄！你直接传DIBSection的HBITMAP给CF_DIB，类型完全不匹配，API肯定会失败。

要使用CF_DIB，你需要把DIBSection的BITMAPINFO和像素数据复制到一块用GlobalAlloc(GMEM_MOVEABLE | GMEM_ZEROINIT)分配的全局内存里，再把这块内存的指针传给SetClipboardData——但这就涉及到你不想做的额外数据复制了。

无需额外复制的解决方案 #

如果你想直接用DIBSection的HBITMAP放入剪贴板且不复制数据，只要做好这几点：

• 严格遵守剪贴板操作流程：先OpenClipboard(NULL)，再EmptyClipboard()，然后调用SetClipboardData，最后CloseClipboard()——少了EmptyClipboard这一步也可能导致图像无法正常写入。
• 调用SetClipboardData成功后，不要销毁HBITMAP，也不要释放DIBSection的像素内存——剪贴板会在合适的时机自动处理这些资源，你提前释放就会破坏剪贴板里的数据。
• 确保DIBSection使用的是剪贴板支持的格式，比如用BI_RGB压缩模式（避免用BI_BITFIELDS，除非你已经正确设置了颜色掩码）。

给你一个正确的示例代码片段：

// 假设已经通过CreateDIBSection创建好hDIBSection和lpvBits
if (OpenClipboard(NULL)) {
    EmptyClipboard();
    // 将DIBSection的HBITMAP交给剪贴板
    if (SetClipboardData(CF_BITMAP, hDIBSection)) {
        // 这里不要调用DeleteObject或释放lpvBits！
        MessageBox(NULL, L"图像已写入剪贴板", L"成功", MB_OK);
    } else {
        // 只有Set失败时才需要手动清理资源
        DWORD err = GetLastError();
        DeleteObject(hDIBSection);
        LocalFree(lpvBits);
        MessageBox(NULL, L"写入剪贴板失败", L"错误", MB_OK);
    }
    CloseClipboard();
} else {
    // 打开剪贴板失败，清理资源
    DeleteObject(hDIBSection);
    LocalFree(lpvBits);
    MessageBox(NULL, L"无法打开剪贴板", L"错误", MB_OK);
}

为什么CreateCompatibleBitmap能正常工作？ #

因为它创建的是设备相关位图（DDB），内存完全由GDI内核管理，剪贴板接管后不需要依赖你的进程内存，所以不会出现数据丢失的问题。而DIBSection是设备无关位图（DIB）的GDI包装，像素数据在用户态进程内存里，所以对内存生命周期的要求更严格。

内容的提问来源于stack exchange，提问作者Deep Thought