InvalidateRect详解：窗口重绘机制、参数细节与性能优化实战-开发者社区

在 Windows 桌面开发里，只要跟界面打交道，迟早会碰上窗口重绘这档子事。不管是自绘控件、动态图表，还是简单的状态刷新，背后都绕不开一个核心 API——InvalidateRect。很多初学者刚接触这个函数时，觉得它不就是“让窗口重画一下”嘛，直接调用一下完事。但实际上，这个函数的底层逻辑牵扯到 Windows 消息机制、GDI 绘制的异步模型，以及刷新效率的优化策略。用好了，界面丝滑流畅、CPU 占用低；用不好，满是闪烁、卡顿，甚至在某些场景下反复触发绘制导致性能雪崩。

这篇文章我会从实际项目经验出发，把 InvalidateRect 的机制原理、参数细节、配合技巧和常见场景逐一拆开讲清楚。不管你是刚接触 Win32 编程的新手，还是已经写过一段时间 MFC、WTL 或 DirectUI 的开发人员，只要你要跟窗口重绘打交道，这篇文章都适合你。我会尽量用真实项目的视角讲，不堆砌文档式废话，直接说人话。

1. 为什么需要 InvalidateRect？先理解窗口重绘的底层逻辑

1.1 Windows 不会主动重绘你的窗口

很多人第一次写 Win32 程序都会有个困惑：为什么窗口从后台切回前台时，内容会花掉？为什么拖动窗口边缘缩放时，绘制内容会残影？原因很简单——Windows 不会自动帮你保存窗口上的每一个像素。当窗口被其他窗口遮挡、最小化恢复、或者改变大小时，原来窗口区域内的内容可能已经丢失，系统只记得你要重绘，但不知道你要画什么。

这时候，Windows 的做法是向你的窗口过程（WndProc）发送一个 WM_PAINT 消息。你收到这个消息后，必须调用 BeginPaint/EndPaint（或者 GetDC/ReleaseDC）重新绘制一遍。问题来了：WM_PAINT 不是一个“随时想发就发”的普通消息，它是一个低优先级消息，只有当系统认为窗口的“无效区域”（Invalid Region）不为空时，才会产生 WM_PAINT。

这里的关键概念就是“无效区域”。所谓无效区域，就是窗口上那些“内容已经过期、需要重新绘制”的区域。系统维护着一张内部的 region 表，记录当前窗口哪些地方需要刷新。只有当这张表非空，消息循环里才可能取出 WM_PAINT 消息。

1.2 InvalidateRect 的作用就是标记“这里过期了”

既然如此，那如果你的数据变了、状态变了，你想让某个区域刷新，最直接的方式就是告诉系统：“这部分内容已经是旧的了，请安排重绘。” InvalidateRect 干的就是这件事。

函数原型很简单：

BOOL InvalidateRect( HWND hWnd, // 要标记无效区域的窗口句柄 const RECT *lpRect, // 无效区域矩形，可为 NULL BOOL bErase // 是否擦除背景 );

调用之后，系统会把指定的矩形添加到该窗口的无效区域集合中。这么说吧，InvalidateRect 本身不会立即触发任何绘制，它只是在系统那里“挂了个号”，说这块地方需要更新。真正的绘制动作，要等到应用程序回到消息循环，系统派发 WM_PAINT 时才发生。

我可以打个比方：InvalidateRect 相当于你在工单系统里提交了一个“维修申请”，WM_PAINT 才真正执行维修任务。申请先到先排队，维修工什么时候来，取决于当前有没有其他更紧急的活儿。

这个异步机制很关键，也是很多人 InvalidateRect 用不好的根本原因。因为没有理解“标记”和“执行”是分离的，导致很多人以为调用完 InvalidateRect，窗口立刻就会重画，结果发现有时候没有立刻刷新、有时候又莫名其妙刷了好几次。

1.3 理解异步重绘：为什么 InvalidateRect 不立即画

跟 InvalidateRect 经常一起出现的还有一个函数叫 UpdateWindow。UpdateWindow 和 InvalidateRect 的区别在于：UpdateWindow 会强制立即发送 WM_PAINT，而不是等消息循环慢慢派发。如果无效区域非空，UpdateWindow 会跳过消息队列，直接调用窗口过程完成绘制，效率更高、响应更快。

举个实际例子。你在按钮点击事件里修改了一个数据，然后希望界面立刻反映出来。你可以：

// 方案 A：只标记，等系统安排 WM_PAINT（通常很快，但有延迟） InvalidateRect(hWnd, NULL, TRUE); // 方案 B：立即强制重绘，适合需要立刻反馈的场景 InvalidateRect(hWnd, NULL, TRUE); UpdateWindow(hWnd);

方案 B 中，InvalidateRect 先标记无效区域，UpdateWindow 紧接着强制同步发送 WM_PAINT，这样窗口的内容就会在函数返回前完成重绘。看起来差不多，但体验差别很大。特别是在窗口最小化、或者系统消息队列繁忙时，只调 InvalidateRect 可能会有明显延迟感，配合 UpdateWindow 就能获得即时反馈。

但要小心：如果你在循环里频繁调用 InvalidateRect + UpdateWindow，那效率极低，因为每一次都会触发一次真正的绘制，CPU 立刻飙升。这里就牵涉到下一节要讲的参数细节和场景取舍。

2. InvalidateRect 三个参数背后的真正含义

2.1 参数一：hWnd——你要刷新谁的窗口

这个参数看起来最没技术含量，其实最容易踩坑。hWnd 需要的是一个顶层窗口或者子窗口的句柄。但很多人忽略了一个细节：InvalidateRect 只对指定的那个窗口产生无效区域，它不会自动连带刷新子窗口。如果你的窗口上有子控件（比如一个按钮、一个编辑框），你只刷新父窗口，子控件的内容不会跟着重绘——除非子控件自己也收到了无效化标记。

实际项目中碰到过一个场景：一个自定义控件的父窗口背景变了，但是子控件区域保留着旧的背景色。检查了半天发现，父窗口的 WM_PAINT 里只调用了 InvalidateRect(hParent, ...)，而没有针对子控件做处理。解决办法很简单，要么明确让子控件也 InvalidateRect 一下，要么在父窗口刷新时向子窗口发送 WM_ERASEBKGND 或调用 RedrawWindow 带上 RDW_ALLCHILDREN 标志。

所以给出一个经验法则：如果你要全窗口刷新，尽量用 RedrawWindow 而不是 InvalidateRect，因为 RedrawWindow 可以指定重绘范围是否覆盖子窗口。原因是 RedrawWindow 提供了更精细的控制。比如：

// 刷新父窗口 + 所有子窗口，立即执行 RedrawWindow(hWnd, NULL, NULL, RDW_INVALIDATE | RDW_ERASE | RDW_ALLCHILDREN | RDW_UPDATENOW);

如果坚持用 InvalidateRect，就一定要想清楚你的目标窗口是谁。特别是自绘控件内部操作时，很多人直接 InvalidateRect(hCtrl, NULL, TRUE)，这没问题；如果你的逻辑写在了获取到的其他窗口句柄上，就得确认是不是你真正想刷新的窗口。

2.2 参数二：lpRect——区域控制决定重绘的开销

lpRect 是一个指向 RECT 结构的指针，表示需要无效化的矩形区域。传 NULL 表示整个客户区全部无效。这个参数很多人不当回事，每次都传 NULL，结果在性能敏感场景下吃了大亏。

举个实际例子。我在做一个波形显示控件，波形刷新是逐点推进的。如果用 NULL 整窗口无效化，那每次刷新都要重绘整个坐标轴、网格线、历史波形和当前波形，CPU 占用直接拉满，而且画面会明显闪烁。但如果你知道当前只需要画那一小块新数据区域，你可以精准地指定那个矩形区域：

RECT rcUpdate; rcUpdate.left = nNewStartX; rcUpdate.right = nCurrentX + nWidth; rcUpdate.top = rcClient.top; rcUpdate.bottom = rcClient.bottom; InvalidateRect(hWnd, &rcUpdate, FALSE);

这样做之后，GDI 在做区域裁剪时，只需要重绘这一小块，其他区域的内容保持不变，速度提升不是一点半点。实测下来，这种方式在处理高频刷新的信号曲线、频谱图时特别管用，CPU 占用可以降低 50% 以上。

需要注意一点：lpRect 使用的是客户区坐标，不是屏幕坐标，也不是窗口坐标。如果你的计算坐标来自鼠标位置（如 WM_MOUSEMOVE 的参数），那本身是客户区坐标，可以直接用。但如果坐标来自其他地方，一定要先 ScreenToClient 做转换，否则你标记的无效区域位置就错了，导致刷不出来或者刷错位置。

还有一种情况：一次性标记多个不连续的小区域。InvalidateRect 只支持矩形无效区域，如果是要标记多个不相邻区域，你可以连续调用多次 InvalidateRect，系统会把几个矩形区域合并到同一个无效区域集合里，最终产生一个 WM_PAINT，而不是每个矩形一次。这里体现的是无效区域合并机制的优势。这种情况下你不需要担心每次调用都导致一次重绘，因为 Windows 会在发出 WM_PAINT 前做区域合并。所以连续多次调用 InvalidateRect 并不会明显增加重绘次数，前提是这些调用都发生在同一条消息处理过程中，系统没有机会在中间插队发送 WM_PAINT。

2.3 参数三：bErase——擦不擦背景，直接影响闪烁与否

bErase 参数表示在重绘之前是否要擦除背景。传 TRUE，系统会在发送 WM_PAINT 之前（确切说是在处理 WM_ERASEBKGND 时）用窗口背景色擦除无效区域；传 FALSE，则保留原背景，直接在上面重绘。

这个参数的坑非常深。说深是因为很多人根本没意识到：闪烁的根源，很多时候不是绘制太慢，而是先擦除后绘制之间的时间间隔造成的空白帧。当 bErase = TRUE 时，系统先把你旧的内容擦成背景色，然后才开始画新的内容。如果画新内容需要几十毫秒，那在普通用户看来，窗口会先闪一下白（或背景色），再显示出新内容。特别是刷新频率较高时，这种闪感非常明显。

解决闪烁的经典方案之一，就是在 WM_ERASEBKGND 处理中直接返回 TRUE（告诉系统“我已经处理完背景了”），然后在 InvalidateRect 传 FALSE，避免重复擦除。举个例子：

case WM_ERASEBKGND: return 1; // 告诉系统：背景已经清好了，别再擦了

然后刷新的地方：

InvalidateRect(hWnd, &rcUpdate, FALSE);

这样系统不再默认擦除背景，而是直接在原背景上绘制新内容。如果你是完整重绘（即每次 WM_PAINT 都会把整个客户区重画一遍），那这样做几乎不会产生任何闪烁。因为所谓的“旧背景”已经被你的新绘制完全覆盖了。

这里有个很微妙的道理：如果你在 WM_PAINT 里只是部分绘制而不是全量绘制，那 bErase = FALSE 可能会出现“残影”——旧的内容没被擦掉，新内容叠加在上面。所以 bErase 的选择要配合你在 WM_PAINT 里的绘制逻辑来决策。我的经验是：

如果 WM_PAINT 里是全量重画（整个无效区域都会重新绘制），那就用 FALSE，配合自行处理背景，基本零闪烁。
如果 WM_PAINT 里只画部分内容，并且依赖背景擦除来清理旧画面，那就不适合盲目用 FALSE，需要自行设计背景清理逻辑。

3. InvalidateRect 的搭档们：UpdateWindow、RedrawWindow、InvalidateRgn

3.1 UpdateWindow：强制同步，消灭等待感

前面提到过，InvalidateRect 和 UpdateWindow 常常配合使用。因为 InvalidateRect 只排队，UpdateWindow 负责插队执行。从机制上讲，UpdateWindow 直接向窗口过程发送 WM_PAINT 消息，但有个前提：窗口的无效区域必须非空。如果无效区域为空，UpdateWindow 什么也不做，也不会强迫窗口重绘。

这就导致一个常见的诡异 bug：你调用了 InvalidateRect(hWnd, NULL, TRUE) 之后紧接着调用 UpdateWindow(hWnd)，按理说肯定能触发 WM_PAINT。但如果你在第一次 InvalidateRect 之前，又偶然调用了 ValidateRect 或者 RedrawWindow 加上了 RDW_NOINVALIDATE 之类的标志，无效区域被清空了，UpdateWindow 就白调了。

我建议的做法是：如果每次刷新都要“标记 + 执行”一起做，直接封装一个辅助函数：

void ForcePaint(HWND hWnd) { InvalidateRect(hWnd, NULL, TRUE); UpdateWindow(hWnd); }

这个函数比单独用 InvalidateRect 实时性强很多。在用户交互中，如果需要即时视觉反馈（比如鼠标拖拽移动一个图形），用这个方案，画面能跟手；如果只用 InvalidateRect，鼠标拖拽时就会出现画面慢半拍的情况。原因是 InvalidateRect 的要等消息循环返回才处理，而拖拽过程中消息队列里可能有大量鼠标消息排队，WM_PAINT 优先级又低，所以实时性很差。

3.2 RedrawWindow：更精细的重绘开关

RedrawWindow 可以看作 InvalidateRect 的“超集”增强版，它把无效化、擦除、立即重绘、是否波及子窗口等操作全部揉在一个函数里，通过标志位控制：

BOOL RedrawWindow( HWND hWnd, const RECT *lprcUpdate, HRGN hrgnUpdate, UINT flags );

核心 flags 大致分四组：

RDW_INVALIDATE：标记区域内无效，等同于 InvalidateRect
RDW_ERASE：擦除背景（受 WM_ERASEBKGND 控制）
RDW_UPDATENOW：立即发送 WM_PAINT，等同于 UpdateWindow
RDW_ALLCHILDREN：连带刷新所有子窗口

举个例子，想实现“刷新整个窗口包括子控件、擦除背景、立即重绘”，一封调用就能搞定：

RedrawWindow(hWnd, NULL, NULL, RDW_INVALIDATE | RDW_ERASE | RDW_UPDATENOW | RDW_ALLCHILDREN);

这个调用等价于：

InvalidateRect(hWnd, NULL, TRUE); UpdateWindow(hWnd); // 外加对所有子窗口递归执行 RedrawWindow

区别在于，RedrawWindow 对子窗口的处理是递归式深入遍历，而如果只单独调用 InvalidateRect(hWnd, NULL, TRUE)，子窗口不会自动刷新。所以，当你的界面层级复杂时，优先考虑 RedrawWindow 而不是 InvalidateRect。从性能角度看，RedrawWindow 把多条操作合并到一次调用里，减少了多次进入 Win32 层的开销。

3.3 InvalidateRgn：脱离矩形限制

InvalidateRect 只能标记矩形区域，但实际绘制中经常需要刷新的区域并不是矩形。比如不规则图形被外部数据更新，或者你只想刷新某个多边形/椭圆区域。这时候可以用 InvalidateRgn：

BOOL InvalidateRgn( HWND hWnd, HRGN hRgn, BOOL bErase );

用法上跟 InvalidateRect 几乎一样，只是第二个参数从 RECT* 换成了 HRGN。你可以先用 CreateRectRgn、CreateEllipticRgn 或者 CombineRgn 构造任意形状的区域，再传给 InvalidateRgn。

注意：函数内部会对传入的 HRGN 做一个拷贝，所以你可以在调用完之后立即 DeleteObject 释放句柄，不会影响系统后续的重绘流程。这个细节很多人不知道，导致每次调用 InvalidateRgn 前创建区域，调用完却忘记删除，最终 GDI 句柄泄露。跑久了程序会因为 GDI 对象耗尽而画不出东西，甚至崩溃。

我自己写不规则按钮控件时用过 InvalidateRgn。按钮形状是个圆角矩形，普通 InvalidateRect 刷新矩形区域时会连背景一起刷掉，产生细小闪烁；改用 InvalidateRgn 后，只刷新圆角矩形内部的区域，背景部分不受影响，视觉上干净很多。

4. 实战场景：高频刷新和局部重绘如何做到流畅不闪

4.1 高频曲线绘制中的 InvalidateRect 优化

回到前面提到的波形控件，这是一个很典型的 InvalidateRect 高频使用场景。当时的实现逻辑大概是这样的：

采样线程每 10ms 收到一个新数据点，需要把点在波形区域右侧画出来，并且左侧的波形要整体左移。如果采用最粗暴的方案，每来一个点就 InvalidateRect(hWnd, NULL, TRUE)，结果就是：

窗口无效化区域是全部客户区，WM_PAINT 里要绘制全部数据。
bErase = TRUE，系统在每次绘制前擦除整块窗口背景。
高频触发下，闪烁到不忍直视，CPU 占用直奔 20%。

后来改成局部刷新 + 关闭背景擦除，效果立竿见影。

具体做法是：

维护一块内存 DC（memory DC），后台把整个波形完整画到内存 DC 上。
每次采样点到达，只更新内存 DC 中“新增点”的像素。
调用 InvalidateRect，但矩形只框住新增点的区域。
bErase 传 FALSE，因为内存 DC 的更新本来就是完整覆盖那一小块的。

核心代码长这样：

// 新数据点画到内存 DC BitBlt(hMemDC, nNewStartX, 0, nNewWidth, nHeight, hOldDC, nNewStartX, 0, SRCCOPY); // 只刷新新数据区域 RECT rcUpdate = { nNewStartX, 0, nNewStartX + nNewWidth, nHeight }; InvalidateRect(hWnd, &rcUpdate, FALSE);

WM_PAINT 里只需要把内存 DC 对应无效区域 BitBlt 到窗口 DC 上：

case WM_PAINT: { PAINTSTRUCT ps; HDC hdc = BeginPaint(hWnd, &ps); RECT rcInvalid; GetClipBox(hdc, &rcInvalid); // 获取实际需要重绘的区域 int nWidth = rcInvalid.right - rcInvalid.left; int nHeight = rcInvalid.bottom - rcInvalid.top; BitBlt(hdc, rcInvalid.left, rcInvalid.top, nWidth, nHeight, hMemDC, rcInvalid.left, rcInvalid.top, SRCCOPY); EndPaint(hWnd, &ps); break; }

用 GetClipBox 获取系统裁剪后的实际无效区域，是处理局部重绘的核心技巧。BeginPaint 之后 hdc 的裁剪区就是当前需要重绘的部分，BitBlt 只做这块区域的内存拷贝，效率极高。改动之后，波形刷新 CPU 占用降到 2% 以下，而且几乎看不到闪烁。

4.2 拖拽实时预览：InvalidateRect + 橡皮筋画法

另一个高频场景是做图形编辑器里拖拽矩形选择框（橡皮筋效果）。鼠标按下、拖动、松开，期间需要反复刷新选择框的位置。这种场景很适合用 InvalidateRect 的局部无效化配合“异或画法”（XOR）来做，但更推荐的做法依然是双缓冲 + 局部刷新。

常规做法是：

鼠标按下时记录起点。
鼠标移动时，把上一次的选择框矩形区域标记为无效，然后把新的选择框矩形区域标记为无效。
WM_PAINT 里先重画背景图，再在当前鼠标位置画选择框。

这里的 InvalidateRect 区域选择就很重要。如果你只传 NULL，那就是整幅背景图重绘，图片大一点的编辑器（比如 4K 图像、大画布）直接卡顿。如果你精确到上一次矩形和当前矩形的并集区域，开销就小很多：

RECT rcOld; // 旧选择框区域 RECT rcNew; // 新选择框区域 RECT rcUnion; UnionRect(&rcUnion, &rcOld, &rcNew); InflateRect(&rcUnion, 2, 2); // 稍微外扩，避免边缘残余 InvalidateRect(hWnd, &rcUnion, FALSE);

InflateRect 外扩 2 像素是我的一个经验值。如果恰好缩到矩形边界，Border 上的抗锯齿像素可能会残余，看起来有残影。稍微外扩一下，可以避免边缘重绘不干净。选择框拖拽体验直接拉满，画面干净跟手。

4.3 控件内部刷新：避免整窗口重绘

自定义控件内部需要刷新状态时，也要克制整窗口刷新冲动。举个例子，自绘一个音量条，音量变化时只需要刷新音量条那一小条区域。直接 InvalidateRect(音量条窗口, NULL, TRUE) 当然可行，但如果音量条周围还有其他自绘内容且刷新成本高，整窗口刷新就会连累别人跟着重画。

更好的方案：控件内部主动向父窗口申请指定区域刷新：

RECT rcVolumeBar; // 根据控件位置计算出音量条在本窗口里的客户区坐标 rcVolumeBar.left = 10; rcVolumeBar.top = 20; rcVolumeBar.right = 30; rcVolumeBar.bottom = 120; InvalidateRect(hWnd, &rcVolumeBar, FALSE);

这样 WM_PAINT 里系统的裁剪区就只有这个矩形，其他控件的绘制完全不受干扰。如果整个窗口只有一个自绘控件，全窗口刷新问题不大；但一个复杂面板上十几个控件，每个控件刷新都整窗口重绘，那重绘范围互相叠加，性能就会迅速劣化。

我在实际项目里总结了一条规则：能局部，绝不全局；能合并，绝不分散；能异步，绝不同步。这条规则在 InvalidateRect 使用中尤其适用。

5. 高频踩坑：InvalidateRect 使用中的常见问题与排查实录

5.1 调用 InvalidateRect 后界面没有刷新

这是出现频率最高的现象。代码逻辑上明明调了 InvalidateRect，窗口内容纹丝不动。常见原因有这么几个：

无效区域过早被验证。系统可能在其他地方（比如 ValidateRect、ValidateRgn、BeginPaint/EndPaint）验证了该区域。尤其是你在自定义的绘制流程里调用了 BeginPaint/EndPaint 但又没真正绘制内容，这会让系统认为“这块区域已经处理完了”，后面再调 InvalidateRect 标记无效区域，也不会立刻触发重绘。
窗口被禁用。如果窗口句柄对应的窗口已经被 EnableWindow(FALSE) 禁用，系统对某些刷新操作处理不完全，要确认窗口状态。
窗口没有可见区域。窗口最小化或者完全被遮挡时，WM_PAINT 可能不会被派发。最小化窗口的无效区域需要等恢复后才处理。
消息循环阻塞。如果主线程在某个 while 循环里做耗时操作，消息队列无法正常派发，WM_PAINT 永远出不来。这时需要调用 UpdateWindow 强制同步刷新，或者把耗时逻辑放到工作线程去。

排查思路也简单：先在 InvalidateRect 之后打日志确认已经调用，再在 WM_PAINT 里打日志确认收到消息；如果 WM_PAINT 没收到，逐项排查上述四类原因。

有一个隐蔽点，就是 BeginPaint 的使用。只要调用 BeginPaint，系统默认就会把无效区域验证掉（validate）。哪怕你没画任何东西，系统也以为你画完了。所以如果你在绘制分支里误调用了 BeginPaint，并且把返回的 hdc 丢弃了，窗口内容不会更新。这是非常容易踩的暗坑。

5.2 重绘区域不对，内容出现偏移或残影

这种问题多半是坐标系混用导致的。记住一个铁律：InvalidateRect 的矩形是客户区坐标。如果你的数据来自鼠标的屏幕坐标，一定要用 ScreenToClient 转换。

举个常见错误例子：在响应鼠标事件时，代码直接拿了 lParam 里的坐标（这是客户区坐标），这没问题；但如果你调 GetCursorPos 拿到屏幕坐标后没转换就传给 InvalidateRect，那么无效区域会偏移到窗口的左上方区域，导致该刷的没刷，不该刷的刷了一大片。

还有 WM_PAINT 里用 GetClipBox 获取需要更新的区域时，得到的也是客户区坐标，BitBlt 时源和目标坐标都需要按客户区坐标处理。如果混入了窗口坐标（即包含标题栏和边框），整幅画面会出现位置偏移。

残影问题通常出现在 bErase = FALSE 但实际绘制没有全覆盖时。如果你只画了部分像素，旧内容残留，就会表现为“拖影”“花屏”。遇到残影先别怀疑 InvalidateRect，先把 bErase 改成 TRUE 试试，如果残影消失，那问题就出在绘制覆盖率上，而不是无效区域上。

5.3 死循环重绘：WM_PAINT 无限触发

另一种高频问题是在 WM_PAINT 中调用了 InvalidateRect，然后窗口又触发 WM_PAINT，又调用 InvalidateRect，形成一个无限重绘的死循环。表现是窗口 CPU 占用居高不下，风扇狂转。

典型的错误写法：

case WM_PAINT: { // 一些绘制逻辑 InvalidateRect(hWnd, NULL, TRUE); // 错误，这会导致 WM_PAINT 再次触发 break; }

有人以为在 WM_PAINT 里标记无效区域可以让绘制更“彻底”，结果是无限循环。WM_PAINT 的处理原则是：你只需要画当前无效区域的内容，不要没事找事再标记新的无效区域。如果真的需要在绘制完成后安排下一帧绘制（比如动画），也尽量不要直接在 WM_PAINT 里调用 InvalidateRect，而是用一个定时器或单独的动画驱动逻辑来控制刷新频率。原因是 WM_PAINT 里 InvalidateRect 的时机非常危险，系统可能认为你有无限的内容要画，把你的窗口钉在“持续无效”状态。

如果遇到这种死循环，临时排查手段可以把 InvalidateRect 注释掉，CPU 立刻降下来，基本就能确认问题出在这里。

5.4 GDI 资源泄露：每次刷新都新建对象

最后聊一个隐蔽问题——GDI 句柄泄漏。每次刷新在 WM_PAINT 里创建了画刷、画笔、位图，却忘了释放。结合 InvalidateRect 高频刷新，程序跑几十分钟就会出现界面画不出来、控件变黑块等问题。

检查 GDI 泄漏可以用任务管理器，给进程添加“GDI 对象”列，观察数值是否持续增长。实战中写自绘界面，我严格要求所有 GDI 对象的创建和释放配对：

case WM_PAINT: { PAINTSTRUCT ps; HDC hdc = BeginPaint(hWnd, &ps); HBRUSH hBrush = CreateSolidBrush(RGB(255, 0, 0)); HGDIOBJ hOldBrush = SelectObject(hdc, hBrush); Rectangle(hdc, 10, 10, 100, 100); SelectObject(hdc, hOldBrush); DeleteObject(hBrush); EndPaint(hWnd, &ps); break; }

SelectObject 恢复旧对象、DeleteObject 释放新对象，这是最基本的原则。如果你反复创建画刷并且反复刷新，哪怕每次只泄漏一个，高频下也会越来越严重。这一点跟 InvalidateRect 的使用频率直接相关——用得越猛，泄漏越大。

6. 经验总结：InvalidateRect 背后的重绘性能思维

做了这么多年 Windows 界面开发，我的体会是，InvalidateRect 只是整个重绘体系里的一个小入口，但它牵一发而动全身。想真正用好它，你需要建立一套“重绘性能思维”。我把几个核心经验分享在这里，算是给自己留个备份，也希望能帮你少走弯路。

第一，明确区分“标记”和“绘制”。InvalidateRect 负责标记，WM_PAINT 负责绘制。两者分离，意味着你可以将多次标记合并，减少绘制次数。这就是高效重绘的第一层优化。如果你发现窗口频繁重绘，先别急着改绘制代码，看看是不是标记太频繁了。

第二，区域越小，开销越低。GDI 的重绘是受裁剪区约束的，无效区域越大，裁剪区越大，绘制开销越高。能框出精确的矩形，就不要图省事传 NULL。尤其是复杂控件，局部刷新跟全局刷新的性能差异可能是量级的。

第三，bErase 是闪烁的总开关。闪烁的本质是“擦了还没画”的空白期。你如果能做到内存缓冲 + 全量覆盖，直接用 FALSE 即可；如果没有缓冲，至少要学会拦截 WM_ERASEBKGND，别让系统自作主张反复擦除。

第四，高频场景下推荐双缓冲 + 局部 BitBlt。这个组合拳我用了很多年，在图形编辑器、实时波形、动画控件里都很稳。核心思路是后台内存 DC 负责复杂绘制，WM_PAINT 只做一次内存拷贝，InvalidateRect 则负责精准通知系统哪些区域“需要把内存拷贝到屏幕上”。这样，复杂绘制的高成本和屏幕刷新完全解耦，性能自然上去了。

第五，善用调试工具。调试重绘问题，最笨也最有效的方法是在 WM_PAINT 里用 GetClipBox 输出当前无效区域坐标，再对比你设置的 InvalidateRect 区域，一眼就能看出是哪里不匹配。另外，用 Spy++ 观察消息循环，可以清楚看到 WM_PAINT、WM_ERASEBKGND 的消息频率。

我在实际项目中踩过很深的坑，比如一个统计图控件，最初就是无脑 InvalidateRect(NULL)，后来改成局部矩形刷新，CPU 占用从 15% 降到 1%，图表的顺滑度也完全变了样。这个改进前后代码逻辑几乎一样，差的就是对“需要重绘的区域”的理解。

最后再分享一个实用小技巧：如果你的刷新频率非常高，又担心合并后的无效区域过大导致开销增加，可以考虑分批刷新——把频繁变化的区域放到一个较小的矩形内更新，而不频繁变化的背景内容直接画在内存 DC 里不动。这样每次屏幕刷新只是整块内存的一次 BitBlt，开销稳定且可控。这个思路在很多高性能自绘界面里都能用上，算是我留给你的一个进阶方向。