把内存里的位图画到 hdc 上，这问题我在群聊里至少见过几十次：有人拿着一个 BMP 文件或者内存缓冲区，想把内容贴到窗口 DC 上，试了一圈不是空白就是闪屏，要么直接花屏。今天就把这条链路彻底讲透，从“位图在内存里的真正样子”讲到“如何干净利落地显示到 hdc”，里面涉及的 GDI 对象、设备上下文、像素格式这些底层逻辑，都会用大白话拆开揉碎。适合刚接触 Win32 编程的人照着写，也适合已经能画矩形但一碰位图就懵的同学查漏补缺。
1. 先把问题说清楚：位图数据到底“在”哪里，hdc 又是什么
1.1 三种常见的“内存位图”形态
很多人说的“从内存中加载位图”，其实分好几种情况，差别非常大：
- 第一种是内存里有一整份 BMP 文件字节。也就是你从网络下载、从资源包解压、或者自己拼出来的一段数据，开头是 0x4D 0x42（也就是“BM”两个字符），后面跟着文件头和像素数据。这是一份“还没被 GDI 认识”的原始数据，需要你手动解析。
- 第二种是内存里只有 DIB 像素数据。说白了你手里没有文件头，只有 BITMAPINFO 结构加一块 RGB 数据。这种情况常见于图像库解码后的输出，比如你把 PNG 解压完拿到了 24 位或 32 位的位图数组。
- 第三种是内存里已经有一个 HBITMAP 句柄。它是 GDI 创建好的位图对象，但你还没法直接把它贴到屏幕上，因为 GDI 绘图必须通过 HDC 完成，而 HBITMAP 要“选入”某个 DC 才能被使用。
我这里重点讲前两种，因为第三种说到底也是要经过“选入 DC 再 BitBlt”的流程，方法是一样的。核心原则只有一句：GDI 不认识“裸字节”，只认识“选入 DC 的位图对象”；你要先把字节变成 HBITMAP，再把 HBITMAP 选进一个兼容的内存 DC，最后把这个内存 DC 整体拷贝到目标 hdc。
1.2 DC 和 hdc：GDI 的画布模型
先别急着写代码。很多初学者栽在“为什么我拿到的 HBITMAP 不能直接画到窗口”上，根子在于没理解 HDC 是什么。HDC 全称是 Device Context，设备上下文。
你可以把它想象成一块画板。画板上挂了哪些属性：要画的笔刷是黑的还是红的、文字字体是什么样的、当前选择的位图是哪一张、坐标原点在哪。GDI 的每条绘图指令，DrawText、Rectangle、BitBlt，都是针对某一块画板发的。窗口有窗口的画板，内存缓冲区有内存缓冲区的画板，打印机有打印机的画板。你拿到一个 HBITMAP，就好比你手里有一张照片，但你没法直接把照片“贴”到另一张画上，你必须先把照片放到一个透明相册（内存 DC）里，然后把相册盖到目标画布上。
所以“从内存中加载位图并显示到 hdc”这个需求的完整步骤拆开就是：
原始字节 -> 创建 HBITMAP -> 创建内存 DC -> 把 HBITMAP 选入内存 DC -> 用 BitBlt 把内存 DC 的内容拷贝到目标 hdc -> 清理临时对象下面每一节都是在解决这条链路里的一个环节。你先把这个模型印在脑子里，后面遇到任何奇怪报错，都能顺着这条链路定位。
2. 加载方向的选择：LoadImage 能省事，但也有绕不过去的坎
2.1 省事方案：LoadImage 加载资源或文件
如果你的位图是跟着程序走的，并且你是从磁盘文件或者资源节加载，那最省事的是 LoadImage 这个 API：
HBITMAP hBitmap = (HBITMAP)LoadImage( NULL, L"D:\\test.bmp", IMAGE_BITMAP, 0, 0, LR_LOADFROMFILE | LR_CREATEDIBSECTION );LoadImage 会帮你把文件读进来，解析 BMP 或者图标/光标格式，直接返回一个 HBITMAP。配合 LR_LOADFROMFILE 能加载外部文件，配合 MAKEINTRESOURCE 能加载资源，非常方便。
但有一个关键限制：LoadImage 只能读文件路径或者资源 ID，它不接受“内存缓冲区”。如果你的位图数据来自自绘工具、网络协议、加密封包，或者你只是从文件里读了一段字节存在内存里，那 LoadImage 就无计可施了。这时候你只能手动解析字节。
另外还要提醒一句：LoadImage 加载 BMP 时，默认会按照 DDB（设备相关位图）的方式创建，这类位图和你的屏幕颜色格式强相关，跨设备兼容性不如 DIB（设备无关位图）。做通用工具时建议至少加上 LR_CREATEDIBSECTION，让 GDI 创建出和文件信息一致的 DIB Section，避免色彩格式被动转换。
2.2 不省事的方案：从裸数据创建 DIB Section
如果数据已经在自己手里，正确做法是走 DIB 路线。DIB 的全称是 Device Independent Bitmap，设备无关位图，它的意义在于：像素格式由你自己定义，不依赖目标显示器的颜色格式，GDI 在显示时只做“按需转换”。
创建 DIB 的核心 API 是 CreateDIBSection。它非常特别：在创建成功后，会同时给你一个 HBITMAP 句柄，以及一块你可以直接读写的内存指针。你往这块内存里写什么像素，最终 BitBlt 到 hdc 上就是什么图案，等于你把“画布背面的纸”抽出来自己折腾，GDI 只负责在合适的时候把纸上的内容映射到屏幕上。
我实际项目中绝大多数“从内存加载位图”的场景，都是这么解决的。你先把 BITMAPINFO 填清楚，然后调 CreateDIBSection 拿到 pBits 指针，再用 memcpy 把像素数据拷进去，之后这块 HBITMAP 就能和 LoadImage 返回的 HBITMAP 一样使用。
这边就引出来一个非常关键的问题：BITMAPINFO 怎么填。很多人也就是卡在这一步，填错一个字段，出来的画面要么全黑，要么歪七扭八。
3. 核心步骤：把 BITMAPINFO 填对，像素才不会歪
3.1 BITMAPINFO 和 BITMAPINFOHEADER 的字段真相
先看结构体长什么样。BITMAPINFO 实际上是一个“头结构 + 调色板数组”的复合体，我们一般直接操作它开头的 BITMAPINFOHEADER。
BITMAPINFO bmi = {0}; bmi.bmiHeader.biSize = sizeof(BITMAPINFOHEADER); bmi.bmiHeader.biWidth = width; bmi.bmiHeader.biHeight = height; bmi.bmiHeader.biPlanes = 1; bmi.bmiHeader.biBitCount = 32; bmi.bmiHeader.biCompression = BI_RGB;这几个字段一个都不能错。biPlanes 必须是 1，这是 Windows GDI 的硬性规定，写过其他图形 API 的人最容易在这个地方犯迷糊，以为平面数会变。实际上 GDI 体系里它永远是 1。
biWidth 和 biHeight 是你要显示的位图像素宽高，单位是像素。注意 biHeight 的正负号很关键：正值代表位图是“底部-顶部”方向存储，第一行数据是图像的最底行；负值代表“顶部-底部”，第一行数据是图像的最顶行。BMP 文件格式里，绝大多数都是正的 biHeight，也就是底部-顶部存储，所以你把 BMP 文件的数据直接取出来用的时候，最好让 DIB Section 也使用正的 biHeight，两边方向一致，拷贝就不用做翻转处理。
biBitCount 支持 1、4、8、16、24、32。实际操作中我们最常碰两个：24 位和 32 位。24 位就是每像素 3 字节，按 BGR 顺序，没有 alpha 通道；32 位就是每像素 4 字节，按 BGRA 顺序。注意是 BGR 不是 RGB，这个顺序是 Windows BMP 的祖传规矩，和大多数图像库的 RGB 顺序相反，拷贝数据前需要确认来源格式。
biCompression 设为 BI_RGB 表示数据不压缩。如果位图有 RLE 压缩（文件头里就是这么写的），那你得先解压成 BI_RGB，CreateDIBSection 不支持压缩格式的像素。0 值实际上就是 BI_RGB，但建议显式写出来，代码可读性更好。
还有一个坑，biSizeImage。对 BI_RGB 来说，这个字段可以填 0，GDI 会自动计算。但是某些极老的驱动或者某些工具库会强制校验这个字段，稳妥起见我会顺手算一下，公式见下文。
3.2 行对齐：所有歪斜的根源
位图每行数据的字节数不是简单的 width * bytesPerPixel，它必须按 4 字节对齐。这是 Windows 位图最经典的规则，没有之一。
对齐公式是：
rowSize = ((width * bitsPerPixel + 31) / 32) * 4举个例子，一张宽 101 像素的 24 位位图，每像素 3 字节，宽度内存占用 303 字节。303 不能被 4 整除，所以真实的行大小是 304 字节，最后补 1 个字节的填充。如果你直接按 303 字节一行的方式拷贝，从第二行开始每个像素都会错位，画面看起来像斜着的、带条纹的图片。
这也是为什么你在很多老代码里看到有人手写“扫描行”拷贝逻辑，就是为了绕开这个填充。而用 CreateDIBSection 的好处是，你拿到 pBits 指针之后，它的行大小实际上并不是根据你算的那个“规则行”来的，而是根据系统内存对齐策略来的。直白点讲：不要假设内存里每行就是 304 字节，要根据 DIB Section 返回的内存 stride 来决定拷贝位置。
获取真实行大小的方式是 GetDIBits，或者你在创建之前自己用公式算都可以。但在用 pBits + memcpy 密集拷贝的高速场景下，我会建议用下面这个稳妥方式：先创建，再通过 GetObject 查询 BITMAP 结构里的 bmWidthBytes 拿真实跨距。虽然多一步调用，但能避免在奇异机器上踩内存布局的雷。
3.3 拷贝方向：底部-顶部 vs 顶部-底部
这一步是新人最容易画出倒像的地方。假如你的原始 BMP 数据是底部-顶部存储的，也就是读取文件后第一行像素实际上是图片的最后一行，而你在 DIB Section 里用了负的 biHeight（顶部-底部），那两者方向相反，拷贝出来的图像是垂直翻转的。
正确做法是让两者的方向保持一致。两个选择：
- 原始数据是底部-顶部：DIB Section 也用正的 biHeight，然后一次性 memcpy 整块像素数据即可。
- 原始数据是顶部-底部：DIB Section 也用负的 biHeight，同样可以整块 memcpy。
如果你拿到的数据方向和你要创建的 DIB Section 方向不一致，那就只能逐行拷贝。设 src 数据第 i 行的地址：
目标行指针 = (BYTE*)pBits + (height - 1 - i) * realRowSize;这种手写逐行拷贝会慢一点，但也不是不能用。我自己的建议是：拿到数据先确认方向，能在创建 DIB 时保持一致就保持一致，整块 memcpy 是最快的，也最不容易出位错误。
4. 显示到 hdc：BitBlt 与 StretchBlt 到底怎么选
4.1 理解 BitBlt 和 StretchBlt 的参数
位图对象准备好了，内存 DC 也建好了，剩下的一步就是把内存 DC 里的内容“按像素级别搬运”到目标 hdc。GDI 提供两个主力函数：BitBlt 和 StretchBlt。
BitBlt 是等比例拷贝，源矩形和目标矩形大小一致，不做缩放。它的原型是：
BOOL BitBlt( HDC hdcDst, int xDst, int yDst, int wDst, int hDst, HDC hdcSrc, int xSrc, int ySrc, DWORD dwRop );大部分人只要用到位图，最先接触的就是它。dwRop 是光栅操作码，决定源和目标如何合并。最常用的是 SRCCOPY，表示“直接覆盖”，这是 99% 场景你要的。其他还有 SRCPAINT、SRCAND、SRCINVERT，都是做透明或特殊混合效果用的，后面会说。
StretchBlt 是在 BitBlt 的基础上，允许目标矩形和源矩形的尺寸不一致，从而实现缩放。它的原型多出两个参数，意思是你可以指定从源 DC 里抠一块多大的区域，放大或缩小到目标矩形。
实际开发中一个比较膈应的点：StretchBlt 默认的缩放模式是“不处理颜色”，也就是缩小时会丢像素，放大时会出现块状。想让它表现得像正常人，需要先调 SetStretchBltMode，一般设成 HALFTONE，能得到比较好的半色调效果，但代价是速度明显下降。
我的经验是：如果位图尺寸已经和显示区域一致，我会用 BitBlt，又快又不会有锯齿逻辑。如果需要缩放预览，我会把图像先缩放到内存 DC 里，之后再用 BitBlt 一次性贴出去，避免在每次绘制时都进行昂贵缩放。
4.2 完整示例：从内存字节到窗口 hdc
理论说了这么多，直接上一个最小可运行逻辑，方便你理解每个环节怎么串。假设我们已经把一张 32 位 BMP 文件的完整内容读到了 byte 数组里，现在要把它显示到窗口的 hdc 上。
void DrawBmpFromMemory(HDC hdc, const BYTE* bmpData, int dataSize) { // 1. 校验 BMP 文件头 if (dataSize < sizeof(BITMAPFILEHEADER) + sizeof(BITMAPINFOHEADER)) return; if (bmpData[0] != 'B' || bmpData[1] != 'M') return; BITMAPFILEHEADER* pFile = (BITMAPFILEHEADER*)bmpData; BITMAPINFOHEADER* pInfo = (BITMAPINFOHEADER*)(bmpData + sizeof(BITMAPFILEHEADER)); // 2. 填充 BITMAPINFO BITMAPINFO bmi = {0}; memcpy(&bmi.bmiHeader, pInfo, sizeof(BITMAPINFOHEADER)); // 3. 创建内存 DC 和 DIB Section HDC hdcMem = CreateCompatibleDC(hdc); void* pBits = NULL; HBITMAP hBitmap = CreateDIBSection(hdcMem, &bmi, DIB_RGB_COLORS, &pBits, NULL, 0); if (hBitmap == NULL) { DeleteDC(hdcMem); return; } // 4. 拷贝像素数据 const BYTE* srcPixels = bmpData + pFile->bfOffBits; if (pInfo->biHeight > 0) { // BMP 文件默认底部-顶部，行大小按 4 字节对齐 int rowSize = ((pInfo->biWidth * pInfo->biBitCount + 31) / 32) * 4; memcpy(pBits, srcPixels, rowSize * abs(pInfo->biHeight)); } else { // 顶部-底部，直接整块拷贝 memcpy(pBits, srcPixels, ((pInfo->biWidth * pInfo->biBitCount + 31) / 32) * 4 * abs(pInfo->biHeight)); } // 5. 选入内存 DC 并绘制 HBITMAP hOld = (HBITMAP)SelectObject(hdcMem, hBitmap); BitBlt(hdc, 0, 0, abs(pInfo->biWidth), abs(pInfo->biHeight), hdcMem, 0, 0, SRCCOPY); // 6. 恢复并清理，顺序不能错 SelectObject(hdcMem, hOld); DeleteObject(hBitmap); DeleteDC(hdcMem); }注意第 6 步：先恢复旧位图，再删除位图，最后删除 DC。如果你先删了 DC，再删 HBITMAP，某些平台下 DC 还持有位图引用，可能出现图形资源没有立即释放的问题。
这段代码只做演示，生产环境里你不会希望每次画窗口的时候都去创建一次 DIB Section，那样性能会很差。正确做法是把 HBITMAP 和 hdcMem 在初始化阶段创建好并保存，WM_PAINT 里只做 BitBlt，程序退出时统一清理。后面的章节我会专门讲这个生命周期问题。
5. 实操中常见的几个大坑：闪烁、花屏、释放顺序
5.1 为什么会闪屏，以及怎么根治
如果你把图直接 BitBlt 到窗口 hdc，并且窗口在频繁刷新，很容易看到画面闪烁。闪烁的本质是：每一次 WM_PAINT 处理中，窗口先擦除背景（把整块区域涂上背景色），然后你再去画图，这两步之间有间隙，人眼看到的就是一张白底闪一下再出图。
最有效的解决方案就是双缓冲。双缓冲的意思是不直接往屏幕画，而是先往一块内存 DC 上画，全部画完之后，一次性用 BitBlt 把整块内存 DC 贴到屏幕。这个“内存 DC 先行绘制”的思路，和本文前面讲的内存 DC 本质上是同一套机制。
实现双缓冲有两种路线：
- 在 WM_ERASEBKGND 里直接返回 1，阻止系统擦除背景。
- 创建和客户区一样大的内存 DC，在里面完成所有绘图，最后 BitBlt 整体输出。
推荐第二种，因为第一种在遇到窗口大小变化时反而可能出现残影。双缓冲标准流程是：WM_SIZE 时释放旧内存 DC，按新尺寸创建兼容 DC 和兼容位图；WM_PAINT 时先把所有图元画到内存 DC，再 BitBlt 到屏幕。这套逻辑同样可以复用你当前的内存位图加载逻辑，所以学好内存 DC 机制，实际上是在为整个 GDI 高效渲染打地基。
我自己的实战体会是，做 GDI 动画或者绘制工具时，除了双缓冲，还要注意别在 WM_PAINT 之外主动调用 UpdateWindow 或者 RedrawWindow 去做强制刷新，这会让双缓冲形同虚设。
5.2 花屏和颜色异常的原因
花屏这个词其实能拆成很多具体症状，我工作中遇到最多的情况是这三种：
第一，格式不匹配。你手里是 24 位像素数据，但你创建 DIB Section 时声明成 32 位，或者反过来。这样 GDI 会把每个像素读错宽度，画面就会呈条状倾斜。症状描述通常是“看起来像被撕碎的照片”。
第二，行对齐算错。这个问题前面讲过了，老代码里最容易出现的是按 width*bytesPerPixel 直接算行大小，没做 4 字节对齐。只要你显示的是畸形条纹图，优先怀疑行对齐。
第三，垂直倒置。把底部-顶部当成顶部-底部，或者反过来，整张图上下颠倒。flutter 的图片、某些 UI 引擎输出的 RGB 数据都习惯顶部-底部，而 BMP 文件多数是底部-顶部，转换接口没做好就会出现颠倒。
排查逻辑我给一个固定顺序：先看颜色对不对，不对就查像素顺序和位深；再看行有没有歪，歪了就查对齐；最后看方向，倒了就改 biHeight 的正负号。这条链路我走了无数遍，十有八九都能定位。
5.3 清理顺序的细节：GDI 句柄泄漏怎么避免
GDI 对象和普通堆内存不一样，你 DeleteObject 之后句柄才释放。再强调一次正确顺序：
1. SelectObject 恢复旧对象 2. DeleteObject 删除我们创建的 HBITMAP 3. DeleteDC 删除内存 DC顺序颠倒最常见的情况是：你创建的内存 DC 里还选着位图，直接 DeleteDC 了。这不会立刻崩溃，但会导致该位图对象引用计数没被妥善处理，在追求长时间稳定运行的服务型工具里，GDI 对象数会缓慢增长，最终超过系统上限，表现为全部新的 GDI 创建调用失败，界面变得空白、异常。
另外一个经验：如果你的程序里存在大量位图对象，建议封装一个小助手类，构造函数里创建对象，析构函数里按下述顺序清理，避免遗漏。哪怕是 C 语言写的 Win32 程序，也可以用一个局部结构体变量来管理这些句柄，函数退出时统一清理。
6. 常见问题速查表：对着症状找原因
这个表是我在解决各种相关问题时的自查清单，有类似毛病直接对着查。
| 症状 | 最可能原因 | 解决方向 |
|---|---|---|
| 画面全黑，但 BitBlt 返回 TRUE | DIB Section 的 pBits 没有写入有效数据，或写入数据后未调用 GdiFlush | 确认 pBits 的写入确实发生，必要时调用 GdiFlush |
| 图像左右或上下颠倒 | biHeight 正负号方向不一致 | 统一 DIB Section 方向与源数据方向 |
| 条纹状花屏 | 行对齐算错，或者每像素字节数与 biBitCount 不匹配 | 用 4 字节对齐公式重算行大小 |
| 颜色发蓝发红，通道对调 | 像素顺序 BGR vs RGB 没有转换 | 按 BGRA/BGR 顺序排布数据 |
| 显示时出现边框锯齿 | 目标尺寸和源尺寸不同，用了 StretchBlt 但没设模式 | SetStretchBltMode(HALFTONE) 或预缩放到内存 DC |
| 窗口拖动时闪烁 | 未做双缓冲，WM_ERASEBKGND 干扰 | 建立内存 DC 整体 BitBlt，或处理 WM_ERASEBKGND |
| 程序长时间运行后 GDI 句柄爆炸 | 创建 DIB 和 DC 后没有释放，或释放顺序错误 | 先恢复旧对象，再删位图，最后删 DC |
| 图像模糊、像打了马赛克 | 使用 StretchBlt 默认放大模式 | 改成半色调模式，或者目标尺寸与源尺寸保持一致 |
| BitBlt 返回 0，GetLastError 无有效信息 | hdcSrc 或 hdcDst 无效，或源 DC 中没有选入位图 | 创建内存 DC 后忘记 SelectObject |
| 在 8 位/16 位色深显示环境下颜色完全错乱 | 没有考虑调色板或高彩色转换 | 使用 32 位 DIB Section，让 GDI 自动做颜色转换 |
一眼望过去，大多数问题的核心都落在“DC 里的对象状态”和“内存数据的几何布局”这两类上。记住这句话，你排查的时候就不容易跑偏。
7. 个人实战体会：不要把加载和绘制搅在一起
最后聊一点架构层面的体会。我见过很多人把“创建位图、建立内存 DC、BitBlt”全部塞进 WM_PAINT 里，程序功能上没毛病，但性能一塌糊涂。原因在于 CreateDIBSection 是一个成本不低的调用，它要分配显存/内存、建立 GDI 对象、还可能触发驱动级的格式转换，放在每一帧去调用，等于把绘图的一部分成本强行打进了每帧开销。
合理设计应是这样：
- 程序启动或者首次需要位图时，一次创建 HBITMAP 和内存 DC，后续一直复用。
- 窗口尺寸变化时，可能需要重新创建兼容位图，但像素内容可以通过 StretchBlt 在内存 DC 之间流转。
- 绘制时只做 BitBlt 或者 StretchBlt。
- 程序退出时统一清理。
也就是说，“加载”和“绘制”是两个生命周期完全不同的阶段。加载可以是秒级、毫秒级，但绘制是被反复调用的高频路径。高频路径里只保留最轻量的 API，这是 Win32 绘图性能优化的第一原则。
另外一个小技巧：如果你的源数据本身就是 32 位且带 alpha，那你显示到 hdc 上就不能用 BitBlt，需要改用 AlphaBlend，并把源 DC 的混合方式设置好，不然透明部分会变成黑色或白色块。AlphaBlend 的用法和 BitBlt 很像，但多一个 BLENDFUNCTION 参数，用来指定 alpha 来源是源像素还是整体常量。这个函数同样要求源 DC 和目标 DC 是兼容的，所以前面兼容 DC 的创建逻辑仍然适用。
还有一点值得留意：内存 DC 创建出来之后，你并不是非得每次都用 CreateCompatibleDC。如果目标窗口的像素格式比较特殊，比如深色模式下某些显示器还是 8 位色深，兼容 DC 创建的位图格式会和屏幕“拧”在一起。你完全可以直接用 CreateDIBSection 配合 DIB_RGB_COLORS 创建一个纯 32 位位图，这样你的内存渲染和最终显示格式完全解耦，GDI 在 BitBlt 时再统一转换。代价是转换有性能损失，但换来的是跨设备一致性，在很多图形工具里我认为是值得的。
踩过足够多的坑之后，我发现“从内存中加载位图并显示到 hdc”这件事，本质就是一种可控的内存渲染模型。你把任意来源的图像数据，先变成 DIB Section 的像素数组，再通过一次拷贝操作统一输出，既解决了文件格式不同的问题，又天然规避了闪烁和撕裂。同时它也是 GDI 双缓冲、高效动画、图像预览这些进阶技巧的共同底座。代码看起来不过二十几行，但把这些环节理解透，后面再看 Direct2D 或者兼容 DC 的高级用法，都会有种“原来是这么回事”的贯通感。
