Win32 C++消息循环、窗口与GDI线程实战源码解析

简介：《精通Windows API——函数、接口、编程实例（源码）》配套源码包，面向有C++基础、希望深入Win32桌面开发与系统级编程的读者，围绕窗口管理、消息循环、动态库加载、COM接口、文件与多线程等主题，用可编译实例降低API学习门槛。压缩包共1789个文件、约24.29MB，含c/cpp/h源码、sln/vcproj工程、exe与dll/lib运行组件，以及pdb/ilk调试符号、obj/manifest构建中间文件和htm说明文档，便于还原工程、调试与对照学习。已有376人学习。读者可循源码理解156个实例的组织方式，掌握CreateWindowEx、SendMessage、GetMessage、LoadLibrary/GetProcAddress及IUnknown等调用路径，并借助工程配置、资源脚本与调试文件排查编译链接问题，适合作为Windows开发练习与查阅资料。

1. 别急着拖控件：一份能跑通的最小 Win32 骨架

做 Windows 桌面方向的课设，十个人里有八个是从拖控件开始的：界面摆好、按钮双击、填几行响应代码，运行起来像模像样。可一旦被追问“窗口过程是谁调用的”“消息从哪儿来”“句柄失效之后会怎样”，当场就答不上来。

Win32 C++ 的价值就在这里。它把 Windows API 的函数、接口和消息机制原样摊开，没有框架替你兜底：每一条消息的流向、每一个句柄的归属、每一次系统调用的返回值，你都得自己交代清楚。这份《精通Windows API-函数、接口、编程实例(源码)》按知识点组织成一个个能独立编译的编程实例，配全套源码，覆盖窗口、GDI、文件、注册表、进程线程这些绕不开的模块。

它适合三类人：要交一份能被追问的 Windows 课设或毕设的学生，需要写小型系统工具的在职开发者，以及接手老 Win32 工程、想快速摸清接口的维护者。下面按需求、架构、实现、验收的顺序，把整套东西拆开讲，代码块可以直接搬进你自己的工程里跑。

2. 需求与技术选型：Win32 C++ 到底该用在哪三类场景

动手写第一行代码之前，得先弄清自己属于哪类需求。不同需求对“用不用原生 API”的答案完全相反，选错了后面全是返工。

2.1 三类真实需求：课设交作业、小工具开发、老工程维护

第一类是课程设计。典型要求是“做一个带界面的管理系统”，评分点往往不在功能多少，而在你能不能解释清楚底层机制。这类需求选 Win32 是加分的：窗口注册、消息循环、控件通知码，每一层都能讲出所以然。给导师演示的时候，你能指着WM_COMMAND说清按钮点击是怎么变成一次函数调用的，这比界面多漂亮更有说服力。

第二类是小型工具。比如批量改名、日志清理、端口扫描结果整理这类单文件程序，用户拿到手只想双击就跑，不想先装运行库。原生 Win32 编出来的 exe 只依赖系统自带的几个 DLL，拷到同版本系统上直接运行，绿色免安装，这在交付场景里非常实用。

第三类是老工程维护。不少行业软件的界面层还停留在十几年前的技术栈上，源码里全是SendMessage、GetWindowLong这类调用。要改一个行为，得先弄明白原来的消息处理链路。这类场景没得选，只能把 API 摸熟，而且要摸的是“哪一版系统上这个函数的行为变了”这种细节。

三类需求对应三种学习路径：课设要横向铺开知识点，工具要纵向吃透几个模块，维护要按问题反查。源码合集的好处是这三条路都走得通，因为每个实例本身就是独立的。

2.2 选型对比：原生 Win32、MFC 与跨平台框架的取舍

选型这件事，不要只看“哪个写着舒服”，要看交付约束。下面这张表是常见的几种方案在实际项目里的差别，判断依据来自体积、依赖、可控性和学习成本四个维度。

这里有个反直觉的结论：如果你要的是“答辩时讲得清楚”，原生 Win32 反而是成本最低的。跨平台框架帮你把消息循环藏起来了，你省下的是写代码的时间，赔进去的是解释原理的能力。课设答辩最怕的就是这种“会用不会讲”。

另一个常被忽略的点是部署。有些工具要在没有网络、不能装东西的机器上运行，这时候依赖越少越稳。原生 Win32 编出来的程序，只要系统版本对得上，双击就能用，不需要用户做任何准备。

提示：选型时先写下三条硬约束——能不能装运行库、要不要跨平台、答辩要不要讲原理。三条里只要有两条偏向“不能”，基本就锁定原生 API 了。

2.3 工程基线：字符集、平台工具集与链接配置

环境配错是新手最常见的翻车点，而且症状很迷惑：代码明明编译通过，运行时界面全是问号。根因多半是字符集没统一。

现在的做法是一律按 Unicode 建工程，宽字符版本 API 全程到底，不去碰char和TCHAR混用那一套。工程属性里把“字符集”设成 Unicode，然后在代码里统一用wWinMain、CreateWindowExW、MessageBoxW这类带W后缀的函数。显式写后缀而不是靠宏，好处是看代码时一眼知道调的是哪个版本，搜索也方便。

// stdafx.h —— 工程统一入口头，把常用的库和类型定死 #pragma once #define WIN32_LEAN_AND_MEAN // 砍掉 winsock1 等不常用头，缩短编译时间 #define UNICODE // 显式声明 Unicode，避免依赖工程设置 #define _UNICODE // C 运行库侧同步打开宽字符 #include <windows.h> #include <string> #include <vector> // 链接阶段直接指定依赖库，省去在工程属性里逐个添加 #pragma comment(lib, "user32.lib") #pragma comment(lib, "gdi32.lib") #pragma comment(lib, "kernel32.lib") #pragma comment(lib, "advapi32.lib") // 注册表相关接口在这

这段头文件做三件事。第一，WIN32_LEAN_AND_MEAN把不常用的头文件排除掉，编译时间能从十几秒降到几秒，工程大了差别很明显。第二，UNICODE和_UNICODE必须成对定义，前者影响 Windows API 的宏展开，后者影响 C 运行库的字符串函数，只定义一个会出现“API 收宽字符、strlen按窄字符算”这种诡异问题。第三，#pragma comment(lib, ...)让链接器自己找库，工程拷给别人时不会因为漏配依赖而链接失败。

平台工具集按目标系统选。如果交付机器上还跑着较老的系统，就别用最新的工具集，否则可能用到新系统才有的 API，在老机器上加载失败。稳妥做法是在工程里把“目标平台版本”调低一档，编译后拿 Dependency Walker 之类的工具看一眼导入表，确认没有意外的系统依赖。

还有一条血泪经验：调试版和发布版的 CRT 配置要分开。调试版用/MDd，发布版用/MD，两者混用会导致堆在两个不同 CRT 之间分配和释放，症状是随机崩溃，而且崩的位置和真实原因完全对不上。这种问题查起来非常费时间，配置阶段就定死能省掉后面很多麻烦。

3. 总体架构设计：消息驱动模型与四个模块的职责划分

架构这一层，原生 Win32 的骨架其实比框架更清晰，因为它只有一条主线：消息。所有交互最终都收敛到窗口过程这一个函数上。

3.1 消息驱动模型：从输入到窗口过程的完整链路

用户按下一个键，到你的代码收到WM_KEYDOWN，中间走了一条固定链路。系统首先把硬件事件翻译成消息结构MSG，塞进该线程的消息队列；线程的消息循环用GetMessage从队列里取出来；TranslateMessage把按键消息转成字符消息；DispatchMessage根据消息里的窗口句柄找到对应的窗口过程，把控制权交过去。

这条链路有几个容易被忽略的细节。一是消息队列是按线程划分的，不是按窗口。一个线程创建的所有窗口共享同一个队列，所以窗口过程里做耗时操作会卡住这个线程上所有窗口。二是GetMessage有三种返回值：大于零表示取到消息，等于零表示收到WM_QUIT，等于负一表示出错。很多人写成while (GetMessage(...))，把出错当成退出，结果消息循环莫名其妙结束，还查不出原因。三是PostMessage和SendMessage的区别：前者投递到队列立即返回，后者直接调用目标窗口过程并等待返回，在窗口过程里对自己SendMessage会直接死锁。

把这条链路画成文字版的流向，大概是这样：

这张表的价值在于排查。界面卡住时，你按这个顺序从头往后查：是消息没进队列，还是循环退出了，还是窗口过程里阻塞了。有这条链路在，排查就不是瞎猜。

3.2 四个模块的职责边界与目录结构

一份能长期维护的 Win32 工程，不该把所有代码堆在一个main.cpp里。按职责切四个模块，边界清楚，改一处不影响其他。

界面模块负责窗口注册、创建、控件布局和消息分发，只做“把用户操作翻译成业务调用”这件事，不写业务逻辑。绘图模块负责所有 GDI 绘制，包括内存 DC 的创建、位图管理和刷新时机。数据模块负责文件读写、注册表访问和配置持久化，向上提供结构化接口而不是裸句柄。系统模块负责进程、线程、同步对象和系统信息查询，是唯一允许直接调用CreateProcess这类接口的地方。

对应的目录结构大致这样：

这样切的好处是编译依赖单向。gdi/不依赖任何人，改绘图不会牵连别的模块；app/依赖所有人，但它只做装配，代码量很小。学生做课设时照这个结构摆文件，答辩时打开目录就能讲清模块划分，比讲一堆功能点有说服力。

3.3 接口约定：句柄封装、错误码与统一日志

Win32 里所有资源都是句柄，句柄是裸的void*或整数，编译器不会帮你检查是否已经关闭。三个约定能挡掉大部分资源类问题。

第一个约定：谁创建谁释放，并且用 RAII 包起来。写一个极简的句柄包装类，构造时接管，析构时关闭，禁止拷贝，允许移动。这样函数中途return也不会漏。

第二个约定：所有可能失败的系统调用必须检查返回值，并且立刻取GetLastError。这里有个坑，GetLastError的值会被后续调用覆盖，所以要在失败后第一时间取出来存到局部变量，不能等到打日志时再取。

第三个约定：错误码要翻译成人能看懂的文字。FormatMessage能把系统错误码转成描述文本，封装一层，日志里就不会出现“错误 5”这种让人摸不着头脑的东西。

// sys/win_error.h —— 错误码转文本 + 统一日志入口 #include <windows.h> #include <string> // 把 GetLastError 的返回值翻译成可读字符串 std::wstring FormatWinError(DWORD code) { wchar_t* buf = nullptr; DWORD len = FormatMessageW( FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_IGNORE_INSERTS, nullptr, code, 0, (LPWSTR)&buf, 0, nullptr); std::wstring msg = (len && buf) ? std::wstring(buf, len) : L"未知错误"; if (buf) LocalFree(buf); // FormatMessage 分配的内存必须 LocalFree while (!msg.empty() && (msg.back() == L'\r' || msg.back() == L'\n')) msg.pop_back(); // 系统文本自带换行，去掉 return msg + L" (code=" + std::to_wstring(code) + L")"; }

这段代码两个关键点。FORMAT_MESSAGE_ALLOCATE_BUFFER让系统负责分配缓冲区，所以用完必须LocalFree，用delete或free都会出问题。FORMAT_MESSAGE_IGNORE_INSERTS是防止消息模板里有%1这类占位符导致格式化异常。最后的去换行是细节，系统返回的文本末尾带\r\n，直接拼进日志会把格式打乱。

日志本身建议按级别分文件写，调试信息一个文件，错误一个文件，出问题时先看错误文件。写日志用WriteFile追加模式，别用fopen，因为多线程环境下 FILE* 不是线程安全的。

4. 关键模块实现：窗口、GDI、文件与线程的代码落地

前面讲的是骨架，这一章填肉。四个模块各给一段可以直接编译的核心代码，并说清楚参数怎么改、失败看哪里。

4.1 窗口创建与消息循环的可复用骨架

任何 Win32 程序都是从这段开始的。写熟了之后你会发现，除了类名和初始尺寸，剩下的几乎一模一样，完全可以做成模板反复用。

// ui/main_window.cpp —— 最小可运行窗口骨架（Unicode） #include <windows.h> LRESULT CALLBACK WndProc(HWND, UINT, WPARAM, LPARAM); int WINAPI wWinMain(HINSTANCE hInst, HINSTANCE, PWSTR, int nCmdShow) { const wchar_t* kClass = L"MainWndClass"; WNDCLASSEXW wc = { sizeof(wc) }; // 第一字段必须是结构体大小 wc.lpfnWndProc = WndProc; // 所有消息的落点 wc.hInstance = hInst; // 模块实例句柄 wc.lpszClassName = kClass; // 类名，CreateWindowExW 靠它查表 wc.hCursor = LoadCursorW(nullptr, IDC_ARROW); wc.hbrBackground = (HBRUSH)(COLOR_WINDOW + 1); if (!RegisterClassExW(&wc)) return 0; // 注册失败直接退出 HWND hWnd = CreateWindowExW( 0, kClass, L"示例窗口", WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, CW_USEDEFAULT, 960, 600, nullptr, nullptr, hInst, nullptr); if (!hWnd) return 0; ShowWindow(hWnd, nCmdShow); UpdateWindow(hWnd); // 触发首次 WM_PAINT MSG msg; // 注意用 > 0 判断：返回 -1 是出错，不能当成正常退出 while (GetMessageW(&msg, nullptr, 0, 0) > 0) { TranslateMessage(&msg); DispatchMessageW(&msg); // 分发到 WndProc } return (int)msg.wParam; } LRESULT CALLBACK WndProc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam) { switch (msg) { case WM_CLOSE: DestroyWindow(hWnd); // 先销毁窗口，不是直接退出 return 0; case WM_DESTROY: PostQuitMessage(0); // 投递 WM_QUIT，循环才会结束 return 0; } return DefWindowProcW(hWnd, msg, wParam, lParam); // 不处理的消息必须还回去 }

参数说明与改动点。hInst由系统传入，代表当前可执行模块，注册窗口类和创建窗口都要用它，两处必须一致，否则CreateWindowExW找不到类。nCmdShow控制窗口初始显示方式，最大化、最小化、正常都在这里。wc.hbrBackground设成COLOR_WINDOW + 1是为了让系统在WM_ERASEBKGND时自动刷背景，如果自己处理背景绘制，这里要设成nullptr，否则会闪。

WM_CLOSE和WM_DESTROY分开处理是刻意的。WM_CLOSE是“用户想关”，你可以在这里弹确认框、保存数据；WM_DESTROY是“窗口已经被销毁”，这时候只管投递退出消息。合在一起写在简单程序里没问题，但一旦要加“未保存提示”，就必须拆开，早拆比晚拆省事。

一个常见误解是以为DefWindowProcW可以不调用。实际上所有你不处理的消息都应该还给它，否则窗口的拖动、缩放、系统菜单全都会失灵，症状很怪：窗口能显示，但拖不动。

4.2 GDI 绘图：双缓冲与资源释放顺序

直接往窗口 DC 上画，刷新时必然闪烁，因为系统先擦背景再画内容，中间那一帧会被看到。双缓冲的思路是先画到内存 DC，画完一次性贴到窗口上，用户看到的就是完整的一帧。

// gdi/painter.cpp —— 双缓冲绘制，避免 WM_PAINT 闪烁 void PaintDoubleBuffered(HWND hWnd, HDC hdcTarget, int w, int h) { HDC hdcMem = CreateCompatibleDC(hdcTarget); HBITMAP hbm = CreateCompatibleBitmap(hdcTarget, w, h); HBITMAP hbmOld = (HBITMAP)SelectObject(hdcMem, hbm); RECT rc = { 0, 0, w, h }; FillRect(hdcMem, &rc, (HBRUSH)GetStockObject(WHITE_BRUSH)); // 业务绘制全部落在 hdcMem 上，正式工程里这层会换成自绘函数 Ellipse(hdcMem, 40, 40, 240, 200); BitBlt(hdcTarget, 0, 0, w, h, hdcMem, 0, 0, SRCCOPY); // 逆序释放：先还原旧对象，再删位图，最后删 DC SelectObject(hdcMem, hbmOld); DeleteObject(hbm); DeleteDC(hdcMem); }

释放顺序是这段代码里最容易出错的地方，也是 GDI 泄漏的主要来源。SelectObject把位图选进 DC 后，位图被 DC 持有，这时候直接DeleteObject会失败（返回值是 0，但很多人不看）。必须先SelectObject把旧对象选回去，解引用之后才能删。

系统对每个进程的 GDI 对象数量有上限，默认是 10000 个。听起来很多，但如果每秒重绘 60 次、每次漏一个，三分钟就到顶，之后所有绘图调用静默失败，界面变成一片白。这种问题不会崩，只会“突然不画了”，非常难查。

BitBlt的最后一个参数SRCCOPY是直接拷贝，如果需要透明叠加就用TransparentBlt，但那个函数在部分老系统上属于扩展库，交付前要确认目标机器上有没有。稳妥做法是能用BitBlt就别用扩展函数。

还有一种优化是缓存内存 DC 和位图，只在窗口尺寸变化时重建。每次WM_PAINT都创建销毁，在 60 帧刷新下开销不小。缓存版本要额外处理WM_SIZE，在尺寸变化时把旧的释放掉重建，逻辑复杂一点，但流畅度提升明显。

4.3 文件与注册表操作的封装

文件读写这块，CreateFile系列函数参数多，出错机会也多。封装一层，把常见的“读整个文件到内存”做成一个函数，调用方就不用关心句柄。

// data/file_io.cpp —— 整文件读取，失败返回 false #include <windows.h> #include <vector> bool ReadWholeFile(const wchar_t* path, std::vector<BYTE>& out) { HANDLE h = CreateFileW(path, GENERIC_READ, FILE_SHARE_READ, nullptr, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, nullptr); if (h == INVALID_HANDLE_VALUE) return false; // 句柄无效要单独判 LARGE_INTEGER size{}; // 超过 1GB 直接拒绝，防止误读大文件把内存吃满 if (!GetFileSizeEx(h, &size) || size.QuadPart > (1LL << 30)) { CloseHandle(h); return false; } out.resize((size_t)size.QuadPart); DWORD read = 0; BOOL ok = ReadFile(h, out.data(), (DWORD)out.size(), &read, nullptr); CloseHandle(h); return ok && read == out.size(); // 读到的字节数也要校验 }

参数含义值得逐条过一遍。GENERIC_READ是访问权限，只读；FILE_SHARE_READ允许别的进程同时读，不加这个的话，文件被别的程序打开时这里会失败；OPEN_EXISTING表示文件必须已存在，不新建；最后一个参数是模板句柄，普通文件传nullptr。

ReadFile的返回值只表示“调用是否成功”，不表示“读满了”。所以最后要额外比较read和期望字节数。文件读取时如果文件正在被写入，可能只读到一部分就返回成功，这时候read < size就暴露了问题。

注册表操作的封装思路类似，但要额外注意键的打开权限。读配置用KEY_READ，写配置用KEY_WRITE，需要同时读写才用KEY_ALL_ACCESS。用最小权限有个好处：在权限受限的账户下跑，能提前暴露“这个程序需要管理员权限”的问题，而不是等到写的时候才失败。

配置读取建议加一层默认值。注册表里没有这个键是正常情况（首次运行），不应该当成错误。封装函数返回“是否取到值”，调用方给默认值，逻辑上更干净。

4.4 进程、线程与同步对象的落地

界面线程不能干重活，这是铁律。一段耗时两秒的计算放在窗口过程里，整个窗口就僵住，标题栏显示“未响应”，用户以为程序挂了。

// sys/worker.cpp —— 工作线程 + 事件对象同步 #include <windows.h> struct JobCtx { HANDLE hStart; // 手动重置事件，置位后线程开工 HANDLE hDone; // 线程完成时置位，主线程等它 volatile LONG stop; // 跨线程停止标志，用原子操作读写 }; DWORD WINAPI WorkerProc(LPVOID param) { JobCtx* ctx = static_cast<JobCtx*>(param); WaitForSingleObject(ctx->hStart, INFINITE); // 阻塞到主线程发令 while (InterlockedCompareExchange(&ctx->stop, 0, 0) == 0) { // 实际业务：解析文件、计算、写日志 Sleep(50); } SetEvent(ctx->hDone); return 0; } // 主线程侧：创建、发令、等待、清理 void RunJobOnce() { JobCtx ctx = {}; ctx.hStart = CreateEventW(nullptr, TRUE, FALSE, nullptr); // 手动重置，初始无信号 ctx.hDone = CreateEventW(nullptr, TRUE, FALSE, nullptr); ctx.stop = 0; HANDLE hThread = CreateThread(nullptr, 0, WorkerProc, &ctx, 0, nullptr); if (!hThread) return; SetEvent(ctx.hStart); // 开工 WaitForSingleObject(ctx.hDone, 5000); // 最多等 5 秒 InterlockedExchange(&ctx.stop, 1); // 通知退出 WaitForSingleObject(hThread, INFINITE); // 等线程真正结束 CloseHandle(hThread); CloseHandle(ctx.hStart); CloseHandle(ctx.hDone); }

几处关键设计。事件对象用“手动重置”，意思是SetEvent之后一直保持有信号状态，直到手动ResetEvent。自动重置的事件在唤醒一个等待者后会自动复位，多线程场景下容易出现“只唤醒了一个”的问题，这里用手动重置更可控。

WaitForSingleObject(ctx.hDone, 5000)带超时，是防止工作线程卡死时主线程永久阻塞。超时后返回WAIT_TIMEOUT，正常工程里应该在这里弹提示并做降级处理，而不是不管。

InterlockedCompareExchange(&ctx.stop, 0, 0)这个写法看着奇怪，作用是原子读。volatile保证编译器不把这个变量优化进寄存器，Interlocked系列保证读写在多核下有序。直接用普通bool做跨线程标志，优化开满时可能永远读到旧值。

线程句柄和事件句柄都要关。CreateThread返回的句柄不关，进程运行期间句柄数会一直涨，长时间跑的工具会出问题。另外，线程函数返回后线程对象还在，必须CloseHandle才真正释放。

注意：CreateThread和 C 运行库的_beginthreadex有区别。如果线程里会用到malloc、new、printf这类 CRT 函数，应该用_beginthreadex，否则可能出现内存管理相关的随机崩溃。纯 Win32 API 调用则无所谓。

5. 避坑与排查：Win32 开发最容易翻车的五个地方

这一章是经验部分。下面五个问题，几乎每个写过 Win32 的人都踩过，按“现象—原因—解决”列清楚，遇到时可以直接对号。

5.1 句柄泄漏：句柄数一直涨

现象：任务管理器里进程的句柄数只涨不降，跑几小时后从几百涨到几万，最终打开文件、创建窗口全部失败。

原因：CreateFile、CreateEvent、OpenProcess、CreateThread这些函数返回的句柄没有对应CloseHandle。多数是在错误分支里return了，正常路径关了，异常路径漏了。

解决：把所有句柄用 RAII 包起来，构造接管、析构关闭、禁止拷贝。函数里有几个return都不怕。另外在调试版里定期打印句柄数（GetProcessHandleCount），涨得快就说明有问题，早发现比晚发现省事得多。

5.2 字符集不一致：编译过了，界面全是乱码

现象：代码编译无警告，运行时界面上的中文全是问号或者方块，日志文件打开也是一堆乱码。

原因：工程设了 Unicode，但某处用了char字符串传给宽字符接口，或者反过来。宏TEXT()和L""混用也会出现这种问题。

解决：全项目统一用wchar_t和L""，所有 API 显式带W后缀。第三方库如果是窄字符接口，在边界处用MultiByteToWideChar转换，转换时明确指定源编码（通常是CP_UTF8），不要用CP_ACP，因为系统默认代码页在不同机器上可能不一样。

5.3 消息循环被阻塞：窗口“未响应”

现象：点一个按钮之后窗口卡住，标题栏变灰显示未响应，几秒后恢复，或者干脆再也不恢复。

原因：在窗口过程里做了耗时操作，比如同步读取大文件、等待网络、Sleep。窗口过程在 UI 线程上执行，它不返回，消息循环就转不动，所有消息堆积。

解决：耗时逻辑挪到工作线程，通过PostMessage把进度回传给 UI 线程，UI 线程只负责更新界面。这里有个细节：工作线程不能直接操作控件，SetWindowText这类函数跨线程调用会失败或者行为异常，必须用PostMessage让 UI 线程自己去改。

5.4 GDI 对象上限与释放顺序

现象：程序跑一段时间后界面突然不刷新了，不崩不报错，就是画不出来。任务管理器里 GDI 对象数接近 10000。

原因：每次绘制都创建画笔、位图、DC，但没有释放，或者释放顺序错了导致DeleteObject失败。SelectObject选进去的对象必须先选出来才能删。

解决：绘制函数里成对写创建和释放，用“逆序释放”的固定模式：先还原旧对象，再删新建的，最后删 DC。调试版里每次绘制后检查GetGuiResources(GetCurrentProcess(), GR_GDIOBJECTS)，超过 2000 就说明有泄漏。

5.5 错误码丢掉了：只看返回值不看 GetLastError

现象：函数返回失败，你知道失败了，但不知道为什么。加日志只能打出“调用失败”，查不下去。

原因：GetLastError的值是线程级的，会被后续任何系统调用覆盖。很多人在失败分支里先做了别的事（比如打日志、关句柄），再去取错误码，取到的已经是别的值了。

解决：失败后第一件事就是把GetLastError()存进局部变量，再做别的。日志里用FormatMessage翻译成文本，加上错误码数字。这条习惯能省掉大量排查时间，尤其是权限类错误（错误码 5，拒绝访问）和路径类错误（错误码 3，找不到路径），一眼就能定位。

6. 验收与答辩：怎么证明这套源码真跑通了

代码写完不等于交付完成。验收要看的是“在别人机器上、在异常条件下，它还稳不稳”。下面这份清单是我每次交付前必过的，按顺序走一遍，能挡掉八成现场翻车。

高 DPI 这一项特别容易被漏掉。不做处理的 Win32 程序在缩放 150% 的屏幕上会被系统拉伸，界面糊成一片。处理方式是在入口处调用SetProcessDpiAwarenessContext声明感知，然后所有坐标按 DPI 缩放比例换算。

答辩环节，最有效的讲法不是罗列功能，而是讲“一条消息的一生”。选一个具体操作，比如点击按钮弹出对话框，从系统产生WM_LBUTTONDOWN开始，讲它怎么进队列、怎么被GetMessage取出、怎么DispatchMessage到窗口过程、怎么在WM_COMMAND里被识别、最后怎么调用到你的业务函数。这条线讲完，评委基本就认可你确实理解了机制。

如果时间只够讲一个技术点，讲双缓冲。先演示不做双缓冲时的闪烁，再演示做了之后的平滑，然后打开代码指出CreateCompatibleDC和BitBlt的位置，最后说清释放顺序为什么不能颠倒。一个有对比、有代码、有原理的演示，比讲十个功能点都管用。

还有个小技巧：把程序里的关键路径加上日志，答辩现场故意制造一个失败（比如把配置文件改名），展示程序如何提示错误、日志里记录了哪些信息。这比演示一切正常更能体现工程能力。

从那以后我每次交付前，都会强制走一遍“干净机器冷启动 + 两小时长稳 + 手动制造一次失败”这三步，哪怕时间再紧也不跳。这三步挡下来的问题，比后面加班改 bug 省的时间多得多。希望帮到你。

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