Win32 API源码实战：窗口消息、GDI绘图与句柄资源管理

简介：面向已具备C++基础、希望系统掌握Win32桌面开发与系统级编程的读者，这份《精通Windows API——函数、接口、编程实例(源码)》配套源码包围绕窗口管理、消息处理、内存与文件操作、动态库加载及COM接口等主题，提供156个可运行的API实例，帮助读者从调用函数过渡到理解Windows程序运行机制。压缩包共1789个文件，约24.29MB，除C/C++源码和头文件外，还包含vcproj、sln工程文件，rc资源脚本、exe示例程序与htm说明页，以及pdb、obj、ilk等调试和中间产物；dll、lib、def等文件便于观察动态链接与模块导出过程。已有376人学习。读者可借助完整工程直接编译调试，对照窗口创建、消息循环、文件读写、多线程和进程间通信等案例复现实验，并通过调试符号与中间文件排查链接及运行期问题，适合作为Windows API课程配套练习和项目开发的查阅素材。

1. 从一个老工具的维护现场说起

上周帮人看一个跑了十几年的采集工具，代码不到两千行，却卡在一个特别原始的问题上：CreateFile打开的句柄在异常分支里漏关了，进程跑满八小时后句柄表耗尽，读写全部失败。翻它的代码，满屏都是 Win32 C++ 的裸调用，没有框架兜底，也没有现成的错误提示，只有一堆GetLastError()返回值没人接。这种代码在业务层看着土，但它离操作系统最近，出问题的地方也最实在。

这份「精通Windows API-函数、接口、编程实例」的配套源码，价值就在这里。它不教你写界面，而是把窗口与消息、GDI 绘图、文件与内存映射、注册表、进程线程、DLL、Winsock 这些 Windows API 的功能域，拆成一个个能单独编译运行的小工程。适合两类人：一是要接手或改造存量 Windows 桌面程序、必须看懂句柄和消息流向的开发者；二是学过 C++ 但没真正碰过 Win32 这层、想拿可运行代码对着文档啃的人。

2. 源码包定位与技术选型：它到底给了你哪些 API 版图

先把预期摆正。这不是一个完整产品，而是一本书的示例集合，每个示例解决一个明确的 API 用法问题。好处是每个工程都很小，几百行就能看完一条完整调用链；代价是工程之间基本不复用代码，你得自己判断哪些片段能抽成公共模块。所以拿到手的第一件事不是编译，而是先看清它覆盖了哪些功能域，再决定哪几个目录值得精读、哪几个扫一眼就够。

2.1 覆盖范围：从窗口消息到跨进程通信的功能地图

按 Win32 的常规组织方式，这类示例集大致会落在下面几个域里。我给每个域补了实际编码时最关键的点和需要额外链接的库，方便你对着自己的需求挑目录。

看表就能判断取舍：如果你在做设备采集类工具，文件、线程、注册表三块是重点；如果做的是上位机界面，窗口消息和 GDI 才是要死磕的部分。不必每个目录都跑一遍，选两三个和自己的场景最接近的示例，读透比泛读十个有用。

2.2 技术选型：纯 Win32、Unicode、零框架依赖

这套示例的技术底座很朴素：C++ 加 Windows SDK，不使用 MFC、不使用 .NET，入口是WinMain/wWinMain，界面全部靠CreateWindowEx一个个建控件。这个选择的直接后果是代码量大、样板代码多，但换来一个好处——你看到的每一行都在和系统打交道，中间没有框架帮你藏东西。

字符集是第一个要定的事。示例代码里出现的TCHAR、L""、_T()宏，都是「可切 Unicode/MBCS」时代的写法。我的建议是全部按 Unicode 编译，也就是在工程属性里把字符集设为「使用 Unicode 字符集」，让TCHAR展开成wchar_t，CreateWindowEx展开成CreateWindowExW。这样和现在的系统 API 行为一致，也避免 MBCS 下中文路径的各种玄学问题。

平台工具集方面，老工程可能是 v100、v110 这类早期版本，直接升级到当前工具集时要留意两处：一是WINVER和_WIN32_WINNT宏，老代码里可能定义得很低，导致新 API 编译不过；二是MultiByteToWideChar之类的调用在新 SDK 里参数检查更严，原来能过的代码可能报 warning。常见做法是先把_WIN32_WINNT提到0x0601（Windows 7）以上，再看编译输出逐条处理。

2.3 环境核对：三步确认工具链能编译它

动手之前花十分钟核对环境，比后面排查链接错误省事得多。

第一步，确认 Windows SDK 装好了。打开「Developer Command Prompt」，敲where cl和where rc，两个都有输出说明编译器和资源编译器都在 PATH 里。rc这条特别容易被忽略，很多示例带.rc资源文件，缺了它编译到一半才报错。

第二步，检查示例工程的目标平台。老工程常见只有 Win32 配置没有 x64，直接在 x64 下打开会提示找不到配置。这时不用改工程，在 VS 的「配置管理器」里新建 x64 平台，从 Win32 复制设置即可。

第三步，先用命令行把单个.cpp编出来，绕开工程文件里的历史包袱。这一步能过，说明 SDK 和源码本身没问题，剩下的都是工程配置问题：

:: 在示例目录下执行，验证单文件能否编过 :: /DUNICODE /D_UNICODE 强制走宽字符，和后面的工程设置保持一致 cl /nologo /EHsc /W3 /DUNICODE /D_UNICODE minimal_win32.cpp ^ /link /SUBSYSTEM:WINDOWS user32.lib gdi32.lib kernel32.lib

/SUBSYSTEM:WINDOWS告诉链接器这是个 GUI 程序，入口是WinMain而不是main；如果漏掉这个参数，链接器会去找控制台的mainCRTStartup，然后甩给你一个LNK2019: unresolved external symbol WinMain——这个报错后面还会细说，它八成不是代码写错了，而是子系统设错了。

3. 目录结构与工程骨架：一个 Win32 程序从入口到消息循环

示例集的目录组织通常跟着书的章节走，每章一个文件夹，每个示例一个独立工程。这种「一例一工程」的排法对学习友好，对复用不友好——你会发现十几个工程里各有一份几乎一样的窗口创建代码。理解这个结构之后，读代码时就可以自动跳过重复部分，只看每个示例真正新增的那几十行。

3.1 目录组织：按章节切分的示例集怎么读

一个典型的目录长这样：顶层是章号命名的文件夹，往下是示例名，示例目录里放.sln（解决方案）、.vcxproj（工程）、一到几个.cpp/.h，可能还有.rc和resource.h。少数示例会带一个ReadMe.txt说明它演示的是哪个 API。

读的时候按这个顺序走最高效：先看.cpp里的WinMain，确认它是不是标准骨架；再找这个示例特有的那几个 API 调用，那才是这个示例的重点；最后看WndProc里处理了哪些消息，因为示例的业务逻辑几乎全塞在窗口过程里。

有一点要提前知道：这类源码里经常出现同一份代码的多个版本，比如xxx_ansi.cpp和xxx_unicode.cpp，或者xxx_old.cpp是书中前一版留下的。遇到编译不过的文件，先确认它是不是被排除在工程之外——VS 解决方案资源管理器里图标是灰的就说明没参与编译，别浪费时间修它。

3.2 最小骨架：WinMain 里的四步走

抛开所有业务，一个 Win32 程序永远只有四步：注册窗口类、创建窗口、跑消息循环、退出。示例代码再花哨，骨架都是这四步，看懂这段就等于拿到了所有示例的阅读地图。

// minimal_win32.cpp —— 去掉业务之后，一个 Win32 程序剩下的就是这四步 #include <windows.h> LRESULT CALLBACK WndProc(HWND, UINT, WPARAM, LPARAM); int WINAPI wWinMain(HINSTANCE hInst, HINSTANCE, PWSTR, int nCmdShow) { // 第一步：注册窗口类。类名是字符串，后续 CreateWindowEx 靠它找回这个类 WNDCLASSEXW wc = { sizeof(wc) }; wc.style = CS_HREDRAW | CS_VREDRAW; // 宽高变化时整窗重绘 wc.lpfnWndProc = WndProc; // 窗口过程，所有消息的终点 wc.hInstance = hInst; wc.hCursor = LoadCursorW(nullptr, IDC_ARROW); wc.hbrBackground = (HBRUSH)(COLOR_WINDOW + 1); // 系统色，不用自己删 wc.lpszClassName = L"DemoWndClass"; if (!RegisterClassExW(&wc)) return 1; // 第二步：创建窗口。这里的 800x600 是窗口外框，客户区要靠 AdjustWindowRectEx 反算 HWND hWnd = CreateWindowExW(0, wc.lpszClassName, L"示例窗口", WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, CW_USEDEFAULT, 800, 600, nullptr, nullptr, hInst, nullptr); if (!hWnd) return 2; ShowWindow(hWnd, nCmdShow); UpdateWindow(hWnd); // 立刻触发一次 WM_PAINT，避免首帧空白 // 第三步：消息循环。GetMessage 返回 0 是 WM_QUIT，返回 -1 才是真错误 MSG msg; while (GetMessageW(&msg, nullptr, 0, 0) > 0) { TranslateMessage(&msg); // 把 WM_KEYDOWN 翻译成 WM_CHAR，别省 DispatchMessageW(&msg); // 派发到 WndProc } return (int)msg.wParam; // 第四步：wParam 就是 PostQuitMessage 传的值 }

几个参数值得单独说。WNDCLASSEXW的cbSize必须赋值，用{ sizeof(wc) }初始化最省事，漏了它RegisterClassExW会直接返回 0 且GetLastError报ERROR_INVALID_PARAMETER。hbrBackground用COLOR_WINDOW + 1这种系统色索引时，系统会帮你管理画刷，你不用也不能删；但如果你换成CreateSolidBrush自己建的画刷，就必须在类不再使用时DeleteObject，否则进程退出前一直漏着。

GetMessageW的返回值别写成while (GetMessageW(...))，看着简洁，实际把-1当成真值继续循环了，出错时会死循环并疯狂占 CPU。写成> 0是血泪经验，多两三个字符，省掉一次难查的 CPU 飙高。

3.3 资源文件与 .rc：图标、菜单、字符串表怎么进程序

示例里凡是带菜单、图标、对话框的，目录下必然有个.rc文件和一个自动生成的resource.h。.rc是资源脚本，编译器rc.exe把它编成.res，再由链接器塞进 exe。resource.h里全是#define IDR_MENU1 101这样的 ID 宏，代码里用LoadMenuW(hInst, MAKEINTRESOURCEW(IDR_MENU1))把它们取出来。

新手最容易卡的地方是改了.rc之后resource.h没同步。VS 的资视编辑器会自己写这个头文件，但你手动改.rc文本时它不会。症状是编译报IDR_MENU1未定义，或者定义了但值和.rc里的对不上，导致LoadMenuW返回 NULL。解决方式很土也很有效：在资源视图里双击一下那个资源再保存，强制 VS 重新生成一遍头文件。

另一个常被忽略的点是资源 ID 的取值范围。手动加 ID 时别用 0 到 15 之间的数，那一段被系统对话框和标准命令占用了。从 100 开始往上排，能避开大部分冲突。

4. 核心模块拆解：窗口过程、GDI 句柄与系统调用三件套

示例代码里真正有价值的部分集中在三处：窗口过程怎么分发消息、GDI 对象什么时候释放、系统资源调用怎么处理错误。这三块构成了 Win32 编程的日常，也是二次开发时最容易埋雷的地方。下面逐块拆。

4.1 窗口过程：一个 switch 撑起全部交互

MFC 有消息映射表，Win32 没有，所有消息都进同一个回调函数，用一个switch分开。这个设计看着粗糙，实际很直接：消息码uMsg决定分支，wParam和lParam的含义随消息变，查文档就行。

LRESULT CALLBACK WndProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam) { switch (uMsg) { case WM_CREATE: { // lParam 是 CREATESTRUCT*，可以把外部传进来的上下文挂到窗口上 auto cs = reinterpret_cast<CREATESTRUCTW*>(lParam); SetWindowLongPtrW(hWnd, GWLP_USERDATA, (LONG_PTR)cs->lpCreateParams); return 0; // 返回 0 表示创建成功，返回 -1 窗口就建不出来了 } case WM_SIZE: // LOWORD(lParam)=客户区宽, HIWORD(lParam)=高；在这里做布局重算 // 不要在 WM_PAINT 里改窗口尺寸，会引起重入 return 0; case WM_PAINT: { PAINTSTRUCT ps; HDC hdc = BeginPaint(hWnd, &ps); // 只在这里画，BeginPaint/EndPaint 会处理无效区裁剪 EndPaint(hWnd, &ps); return 0; // WM_PAINT 必须返回 0 } case WM_COMMAND: // LOWORD(wParam)=命令ID, HIWORD(wParam)=通知码, (HWND)lParam=控件句柄 // 菜单、按钮、加速键的通知全走这一条 return 0; case WM_DESTROY: PostQuitMessage(0); // 不发这句，消息循环永远不退出 return 0; } return DefWindowProcW(hWnd, uMsg, wParam, lParam); // 没处理的全交回去 }

WM_CREATE里那句SetWindowLongPtrW是纯 Win32 里做面向对象封装的关键技巧。它把CreateWindowExW最后一个参数传进来的this指针存到窗口的用户数据槽位，之后在任意消息里用GetWindowLongPtrW(hWnd, GWLP_USERDATA)取回来，就能调成员函数了。注意 32 位下用SetWindowLongW、64 位下必须用SetWindowLongPtrW，写错会导致指针被截断，运行时直接崩——这是升级 x64 时最常见的翻车点之一。

最后那个return DefWindowProcW(...)千万别漏。switch里没匹配到的消息，包括WM_CLOSE、WM_NCPAINT、各种非客户区绘制，都靠系统默认处理。全改成return 0的话，窗口会变得没法最小化、没法拖动边框，甚至关不掉。

4.2 GDI 绘制与句柄生命周期：闪烁和泄漏是一对双胞胎

Win32 的绘图性能问题基本只有两个来源：一是每次WM_PAINT直接往屏幕 DC 上画，擦背景和画内容分离，屏幕就闪；二是建了 GDI 对象没删，进程 GDI 句柄数涨到一万（默认上限）后所有绘图调用静默失败，界面变白板。

标准的解法是双缓冲，示例里只要涉及动画或复杂界面，基本都是这套写法：

void OnPaintDoubleBuffered(HWND hWnd) { PAINTSTRUCT ps; HDC hdc = BeginPaint(hWnd, &ps); RECT rc; GetClientRect(hWnd, &rc); // 用客户区尺寸，不是窗口尺寸 // 1. 建内存 DC 和位图，尺寸与客户区一致 HDC memDC = CreateCompatibleDC(hdc); HBITMAP bmp = CreateCompatibleBitmap(hdc, rc.right, rc.bottom); HBITMAP oldBmp = (HBITMAP)SelectObject(memDC, bmp); FillRect(memDC, &rc, (HBRUSH)GetStockObject(WHITE_BRUSH)); // ... 所有绘制都落在 memDC 上，此时屏幕毫无反应 // 2. 一次性贴回屏幕，肉眼看到的是完整一帧 BitBlt(hdc, 0, 0, rc.right, rc.bottom, memDC, 0, 0, SRCCOPY); // 3. 还原再删除，顺序写反会漏对象 SelectObject(memDC, oldBmp); DeleteObject(bmp); DeleteDC(memDC); EndPaint(hWnd, &ps); }

SelectObject的返回值必须存下来再还原，这一步初学者最常省。原因是位图被选进 DC 期间不能删，你直接DeleteObject(bmp)会失败，而 GDI 的删除失败不报错、不抛异常，只在句柄表里静静挂着。写顺手的判断方法是：只要调了SelectObject，就本能地留一个oldXxx变量，函数结束前倒序还原。

对象数量可以用任务管理器盯着看。在「详细信息」里加上「GDI 对象」和「用户对象」两列，窗口反复打开关闭几十次，这两个数应该回落到起始值附近；如果一路往上涨，就是有对象没删干净。这个方法比事后看代码快得多。

4.3 文件、注册表、线程：系统资源调用的统一套路

这三类 API 长得完全不一样，但处理逻辑是同一套：调用 → 判断返回值 → 失败取GetLastError→ 无论成败都释放句柄。示例里把这套写熟了，你抄到自己的项目里也不会出错。

// 文件：Windows 下路径用宽字符，反斜杠在 C++ 字面量里要转义或用正斜杠 HANDLE h = CreateFileW(L"C:\\data\\config.ini", GENERIC_READ, FILE_SHARE_READ, // 允许别人同时读，独占会导致别的进程打不开 nullptr, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, nullptr); if (h == INVALID_HANDLE_VALUE) { DWORD err = GetLastError(); // 别查 errno，这里只有 Win32 错误码 // 2 = ERROR_FILE_NOT_FOUND, 5 = ERROR_ACCESS_DENIED, 32 = ERROR_SHARING_VIOLATION } else { char buf[4096]; DWORD read = 0; ReadFile(h, buf, sizeof(buf), &read, nullptr); // read 才是实际读到的字节数 CloseHandle(h); // 成功分支要关 }

ReadFile的第四个参数是输出参数，很多人拿sizeof(buf)当读取长度用，结果缓冲区后面全是脏数据。正确做法是看read的值，只处理前read个字节。

// 注册表：写 HKCU 不需要管理员，写 HKLM 在 UAC 下会被重定向或直接拒绝 HKEY hKey = nullptr; LONG r = RegCreateKeyExW(HKEY_CURRENT_USER, L"Software\\DemoApp", 0, nullptr, REG_OPTION_NON_VOLATILE, KEY_READ | KEY_WRITE, nullptr, &hKey, nullptr); if (r == ERROR_SUCCESS) { const wchar_t* ver = L"1.0"; RegSetValueExW(hKey, L"Version", 0, REG_SZ, (const BYTE*)ver, (DWORD)((wcslen(ver) + 1) * sizeof(wchar_t))); // 长度含结尾 0 RegCloseKey(hKey); }

注册表这块有个容易翻车的细节：RegSetValueExW写REG_SZ时长度要包含结尾的\0，也就是(wcslen(s) + 1) * sizeof(wchar_t)。少算这个 1，读出来的字符串末尾就是垃圾字符，界面上显示成方块。

// 线程：C 运行库场景优先 _beginthreadex，CreateThread 在 CRT 里可能漏清理 #include <process.h> unsigned __stdcall Worker(void* param) { // 干活的代码 return 0; } uintptr_t th = _beginthreadex(nullptr, 0, Worker, ctx, 0, nullptr); if (th != 0) { WaitForSingleObject((HANDLE)th, 5000); // WAIT_TIMEOUT 说明 5 秒没干完 CloseHandle((HANDLE)th); }

WaitForSingleObject的超时返回值要看。返回WAIT_TIMEOUT不代表线程挂了，只代表它还在跑，这时候你去CloseHandle是安全的（句柄关了线程还在），但如果后面还想GetExitCodeThread就会失败。示例里一般用INFINITE图省事，真到产品里必须设超时，否则一个卡死的线程能把整个界面拖住。

5. 编译运行与避坑排查：字符集、链接错误与权限

示例代码本身不会骗人，出问题的九成是工程配置和运行环境。这一章按「怎么跑通」和「跑不通怎么办」两段写，前者是操作顺序，后者是我在别人的机器上真见过五次的现场。

5.1 从零跑通：编译、链接与调试设置

打开示例.sln之后，别急着按 F5。先做三件事。

第一，改字符集。工程属性 → 配置属性 → 高级 → 字符集，选「使用 Unicode 字符集」。如果原工程是 MBCS 而代码里混着L""字面量，改过来会冒出一批C2664 无法将 const wchar_t* 转换为 const char*的错误，这些错都是同一个原因：某个函数调了 ANSI 版本。把CreateFile改成CreateFileW、MessageBox改成MessageBoxW就消了。

第二，补附加依赖库。老工程常常靠#pragma comment(lib, "user32.lib")在源码里声明，新工程如果不带这些 pragma，就会在链接阶段报一堆LNK2019。在「链接器 → 输入 → 附加依赖项」里把user32.lib;gdi32.lib;kernel32.lib;advapi32.lib;comctl32.lib;ws2_32.lib一次加全，能省掉反复补库的时间。

第三，设调试工作目录。示例经常要读同目录下的数据文件，VS 默认的工作目录是工程目录而不是输出目录，CreateFile(L"data.bin")会找不到文件。在「调试 → 工作目录」里填$(OutDir)即可。

编译用命令行验证一遍更直观：

:: 完整编译一个带资源文件的示例 rc /nologo /fo app.res app.rc cl /nologo /EHsc /W3 /DUNICODE /D_UNICODE /c main.cpp link /nologo /SUBSYSTEM:WINDOWS /OUT:app.exe main.obj app.res ^ user32.lib gdi32.lib kernel32.lib

分三步走的好处是错误定位清楚：rc报错是资源脚本的问题，cl报错是代码问题，link报错是库或入口问题。一次性cl ... /link会把三类错误混在一起，反而难查。

5.2 排查清单：五类最常见的翻车现场

一、LNK2019: unresolved external symbol WinMain

现象：代码明明有WinMain，链接就是找不到入口。

原因：链接器子系统设成了CONSOLE，它在找main；或者工程里用了wWinMain但没定义WIN32_LEAN_AND_MEAN之外的入口宏，再或者WinMain的签名写错了（比如第三个参数写成LPSTR而在 Unicode 下应该是PWSTR）。

解决：工程属性 → 链接器 → 系统 → 子系统，改成「Windows (/SUBSYSTEM:WINDOWS)」；同时检查入口点，标准情况留空让链接器自动推断，自己填过mainCRTStartup的要清掉。

二、C2664或E0167：const char*与LPCWSTR对不上

现象：一堆函数调用报参数类型不匹配，报错行看起来完全正常。

原因：工程切到了 Unicode，但代码里还有"字符串"这种窄字符字面量，MessageBox(hWnd, "hello", ...)展开成MessageBoxW后就要求LPCWSTR。

解决：字面量统一加L前缀，或者用TEXT("hello")宏跟着字符集走。别用(LPCWSTR)"hello"强转，那是指针重解释，运行时显示乱码。

三、CreateFile一直返回INVALID_HANDLE_VALUE，GetLastError是 5

现象：路径肉眼看着没错，就是打不开。

原因：ERROR_ACCESS_DENIED。可能是在写Program Files下的文件（UAC 会拦），可能是文件被别的进程以独占方式打开（FILE_SHARE_READ没设），也可能是路径里混了正反斜杠导致解析出问题。

解决：先确认目标目录可写，把日志和临时文件放到%LOCALAPPDATA%下；共享模式至少给FILE_SHARE_READ；路径统一用\\或/，别在宽字符串里写单个\。

四、界面在 125% 缩放下错位、文字被截断

现象：在自己机器上布局正常，到高分屏笔记本上按钮全挤在一起。

原因：进程默认是 DPI 不感知的，系统会把整个窗口位图拉伸，坐标全被缩放。

解决：在WinMain最开始调SetProcessDpiAwarenessContext(DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2)，或者工程里加一个 manifest 声明 DPI 感知级别。开了感知之后，所有坐标必须自己按 DPI 换算，不能再用写死的像素值。

五、写 HKLM 注册表返回ERROR_ACCESS_DENIED，但用管理员运行就好了

现象：同样的代码，普通权限下失败，右键管理员运行成功。

原因：Windows 的 UAC 虚拟化只对部分老程序生效，现代 manifest 下写 HKLM 直接被拒。

解决：配置项一律写HKEY_CURRENT_USER\Software\你的应用名；确实需要全局配置的，装的时候写一次，运行时只读。别为了省事给整个程序加管理员权限，那会让拖拽文件到窗口这类功能失效（不同权限级别的进程间拖放会被系统拦掉）。

6. 二次开发：把示例拼成自己的基础模块

示例集最大的问题是重复，每个工程各有一份窗口创建、错误处理、字符串转换代码。真正拿它做项目，第一步不是加功能，而是把这些重复片段抽成一个静态库：win_base.h/cpp里放窗口类注册封装、GetLastError转可读消息的函数、std::wstring与std::string互转、GDI 对象的 RAII 包装。

举个具体的：RAII 包装句柄这件事，抄示例时我一般这样写。HandleGuard里存一个HANDLE，析构时CloseHandle，禁用拷贝、允许移动。这样即使中间抛异常或提前return，句柄也不会漏。同理写一个GdiObjectGuard管HPEN/HBRUSH/HBITMAP，析构时DeleteObject。改完之后，示例里那些「关了这条分支忘了关那条分支」的代码就自然消失了。

改造完必须验证，我的三板斧是：一，在任务管理器里加 GDI 对象和句柄两列，把每个窗口反复开关一百次，看数字是否回落；二，用_CrtSetDbgFlag(_CRTDBG_LEAK_CHECK_DF)打开 CRT 的内存泄漏检测，退出时看输出窗口有没有报告；三，把程序放到一台没装开发环境的干净机器上跑，缺 DLL 和缺运行库的问题只有这时候才暴露。

有个教训我记了很久。早些年改一个示例做小工具，图快，把WM_PAINT里的BeginPaint/EndPaint换成了GetDC/ReleaseDC，本地测一切正常，交出去第三天用户反馈窗口一切换就白屏。原因是GetDC拿到的 DC 不处理无效区，窗口被遮挡再露出来时系统发的WM_PAINT没被正确应答，重绘就丢了。从那以后我每次动绘图代码，都强制走一遍「最小化 → 还原 → 拖动遮挡 → 缩放窗口」这套动作，跑通了才算改完。

这份源码的价值不在于它写得多好，而在于每个功能域都给了你能编译、能打断点、能改一行看效果的最小样本。拿它当字典用，遇到某个 API 记不清参数顺序时翻出对应示例跑一遍，比查文档快。希望帮到你。

本文还有配套的精品资源，点击获取