MFC图形与界面编程实战：GDI绘图、消息映射与双缓冲技巧

简介：这是一份围绕MFC对话框编程的完整示例工程，面向C++/Windows桌面应用开发者，适合想要掌握图形界面编程的入门及中级读者。资源以ShowDialog为项目名，系统演示了从CDialog派生对话框类、重写OnInitDialog进行控件初始化、调用DoModal显示模态窗口，以及通过消息映射响应按钮点击的完整流程；搭配LoginInfo等辅助类，可进一步理解用户输入封装与界面交互逻辑。压缩包共54个文件，主要包含cpp/h源码、rc资源描述、dsp/dsw工程配置、调试符号obj/pch，以及可直接运行的exe，另有ico/bmp图标位图等界面素材，整体仅3.34MB，目录结构紧凑，便于逐文件研读。该资源已有1657人学习，既能作为MFC初学者的实战范例，也可在开发对话框类程序时作为快速参考。

1. MFC 图形与界面编程实例：这份源码包到底有什么能抄

做 Windows 桌面界面开发的人，十有八九在某个阶段撞上过 MFC。它不是新东西，但课程设计、老系统维护、工控上位机里，MFC 的出现频率仍然高得出乎意料。这份「MFC 图形及界面编程实例」源码包，对应的是我刚学 MFC 时最想拿到的那种资源：不是厚厚一本理论书，而是一堆能直接编译、能看效果、能摘走代码的小工程。它解决的核心问题是——当你要画一条线、拉一个滑块、做一个定时刷新动画时，不再去翻零散的 API 文档，而是打开一个现成例子，照着改。

我拆这类实例包的习惯是：先跑起来，再读消息映射，最后才看绘图函数。适合读这篇的人有两类，一类是被课程设计拖着的学生，另一类是维护着老项目、急需找回 MFC 手感的一线工程师。

2. 工程骨架与消息映射：先看清单再编译，MFC 程序不是从 main 开始的

很多人第一次打开 MFC 工程会懵：main 函数在哪？程序怎么就跑起来了？这一章先把骨架讲清楚，再给目录清单和编译步骤。看懂这一层，后面抄图形代码才抄得稳。

2.1 MFC 程序的入口与运行流程

MFC 本质上是对 Win32 API 的 C++ 包装。Win32 窗口程序的入口是 WinMain，但 MFC 把这个入口藏在了基类 CWinApp 里。写 MFC 应用时，你不需要自己写 WinMain，只需要派生一个 CWinApp 子类，重写它的 InitInstance 虚函数即可。

一条完整的 MFC 程序启动链路是这样的：全局的 CWinApp 子类对象构造 → 框架内部的 WinMain 被调用 → 进入 InitInstance → 在 InitInstance 里创建并显示主窗口 → 框架进入消息循环 → 窗口关闭时退出。下面这段是实例里最常见的主框架代码：

class CMyApp : public CWinApp { public: virtual BOOL InitInstance(); // 程序真正开始执行的地方 }; class CMainFrame : public CFrameWnd { public: CMainFrame(); // 构造函数里创建窗口 }; BOOL CMyApp::InitInstance() { m_pMainWnd = new CMainFrame(); // new 一个主窗口对象 m_pMainWnd->ShowWindow(SW_SHOW); // 显示窗口 m_pMainWnd->UpdateWindow(); // 立即发送 WM_PAINT return TRUE; }

这段代码里最容易被忽略的是 m_pMainWnd。这个成员变量指向主窗口，MFC 的消息循环要靠它来分发消息。如果忘了给 m_pMainWnd 赋值，程序运行后窗口一闪就退出，这是新手最常见的「程序没报错但啥也没发生」的根源。SW_SHOW 是显示方式参数，改成 SW_SHOWMAXIMIZED 可以让窗口启动时最大化，在演示类工程里经常这么干。

还有一点值得注意：实例包里的对话框程序走的是 CDialog 路线，InitInstance 里一般用 DoModal() 弹模态对话框；而单文档视图程序走的是上面这段 CFrameWnd 路线。两种骨架不同，但入口逻辑完全一致，都是「构造窗口对象 → 显示 → 进消息循环」。

2.2 消息映射：看懂头文件里的三行宏，比看十遍教程管用

MFC 的事件分发不靠虚函数，而是靠消息映射宏。这是一个静态查找表：消息 ID 对应处理函数指针。这个表由 BEGIN_MESSAGE_MAP 和 END_MESSAGE_MAP 两个宏围起来，放在 .cpp 文件里；头文件里则要声明带 afx_msg 前缀的函数。

// MyFrame.h class CMyFrame : public CFrameWnd { public: CMyFrame(); protected: afx_msg void OnPaint(); // 响应 WM_PAINT afx_msg void OnLButtonDown(UINT nFlags, CPoint point); DECLARE_MESSAGE_MAP() // 声明消息映射表 };

// MyFrame.cpp BEGIN_MESSAGE_MAP(CMyFrame, CFrameWnd) ON_WM_PAINT() // WM_PAINT 路由到 OnPaint ON_WM_LBUTTONDOWN() // 鼠标左键按下 END_MESSAGE_MAP()

ON_WM_PAINT 这类宏做的事情很直接：把 WM_PAINT 消息绑定到 OnPaint 函数。函数签名必须和宏预期的一致，比如 ON_WM_LBUTTONDOWN 要求处理函数必须是void OnLButtonDown(UINT, CPoint)。签名写错不会编译报错，但消息会静默丢失，界面上怎么点都没反应。这种「不报错的故障」在 MFC 里最坑人，排查思路永远是先看消息映射宏和函数签名对不对。

如果你是手动在工程里添加消息处理，记得把 DECLARE_MESSAGE_MAP 放在类声明的最后，否则后面的成员声明可能被宏展开干扰。更省事的做法是用 VS 的类向导生成，实例包里的代码多数也是这么来的。

2.3 源码包的目录结构与编译步骤

解压这类 MFC 实例包后，你会看到按功能拆分的多个独立小工程。每个工程都能单独编译，这很重要——我一般会先挑一个最接近需求的工程跑起来，而不是一股脑把整个解决方案都编译。

一个典型的 MFC 实例工程包含这些文件：

编译步骤比想象中简单，但有一个前置条件容易踩：VS 安装时必须勾选「适用于桌面的 MFC」组件。没勾的话，工程打开后一编译就报「无法打开包括文件 afxwin.h」。如果已经装好了跳过了这个组件，可以去 VS 安装器里修改，勾上 MFC 组件，重启 VS 再编译。

编译操作本身四步：用 VS 打开 .sln → 在工具栏把活动解决方案配置调到 Debug → 选择 x86 或 x64（和本机位数一致即可，MFC 两个平台都支持）→ 生成解决方案。第一次编译会慢一些，因为 MFC 头文件和库的预编译要跑一遍。

注意：Debug 版 MFC 程序依赖调试版运行库，拷贝 exe 到别的机器跑不起来是正常的，发布时要用 Release 配置，这会在第 5 章展开讲。

3. 绘图与 GDI 对象：CDC 双缓冲和四个必踩的内存坑

绘图是这份实例包的重头戏。MFC 里所有画图都发生在设备上下文上，理解 CDC 的三类画布和 GDI 对象的生命周期，比背十个绘图 API 更有用。

3.1 三种设备上下文：CPaintDC、CClientDC 与内存 DC 的取舍

设备上下文是绘图的「画板句柄」。MFC 把 Win32 的 HDC 包装成了 CDC 类，但不同场景要选不同的派生类，选错画布的表现不是报错，而是「画了白画」或者断言崩溃。

View 类的 OnDraw 函数比较特殊，它已经接收了一个 CDC 指针，不需要你自己构造画布。对话框程序里没有 View，要绘图就得手动构造 CClientDC 或 CPaintDC。区分原则很简单：在消息 WM_PAINT 的处理函数里用 CPaintDC，在按钮点击、鼠标移动这种主动绘制场景里用 CClientDC。这条规则记牢，能省掉大半绘图故障。

void CMyDlg::OnPaint() { CPaintDC dc(this); // 只能出现在 WM_PAINT 处理函数里 CRect rc; GetClientRect(&rc); dc.FillSolidRect(rc, RGB(255, 255, 255)); // 先清成白色 }

3.2 OnDraw 画网格与坐标轴：第一笔接触 GDI 对象

绝大多数图形实例的第一步是画网格和坐标轴，因为它同时演示了 CPen、MoveTo、LineTo 三个最基础的绘图元素。下面这段代码来自实例里的坐标演示工程，逻辑完全可以直接抄：

void CMyView::OnDraw(CDC* pDC) { CRect rc; GetClientRect(&rc); // 拿到客户区矩形 CPen penGrid(PS_SOLID, 1, RGB(220, 220, 220)); // 灰色细线 CPen* pOldPen = pDC->SelectObject(&penGrid); // 选入画笔，保存旧画笔 for (int x = 0; x < rc.Width(); x += 20) { pDC->MoveTo(x, 0); pDC->LineTo(x, rc.Height()); // 垂直网格线 } for (int y = 0; y < rc.Height(); y += 20) { pDC->MoveTo(0, y); pDC->LineTo(rc.Width(), y); // 水平网格线 } CPen penAxis(PS_SOLID, 2, RGB(0, 0, 0)); // 黑色轴线，2 像素宽 pDC->SelectObject(&penAxis); pDC->MoveTo(0, rc.Height() / 2); pDC->LineTo(rc.Width(), rc.Height() / 2); // X 轴 pDC->MoveTo(rc.Width() / 2, 0); pDC->LineTo(rc.Width() / 2, rc.Height()); // Y 轴 pDC->SelectObject(pOldPen); // 恢复旧画笔 }

这段代码有四个点值得拆开讲。第一，CPen 是栈对象，函数结束自动析构，不需要手动 DeleteObject，这是最不容易泄漏的写法。第二，每个绘制目标都对应一组 MoveTo 加 LineTo：MoveTo 抬起笔移动到起点，LineTo 落笔画线。第三，SelectObject 的返回值是关键，它保存之前选入 DC 的旧画笔，画完后必须恢复，否则 DC 里残留的画笔状态会带到下一次绘制。第四，网格间距 20 像素是演示值，实际工程里应该把它定义成常量，便于调整。

有人会图省事在 OnDraw 里每次都 new 一个 CPen 分配给堆，这是后面 GDI 泄漏的前兆，第 5 章会专门讲。

3.3 双缓冲刷帧：用 BitBlt 消灭花屏

窗口拉伸时画面闪烁，这是 MFC 图形程序最典型的问题。原因是 WM_PAINT 触发的步骤其实是两步：系统先用背景色擦除客户区，再调用绘图函数画内容。擦和画之间的间隙让视觉上出现一亮一暗的闪烁。

双缓冲的思路是：把所有绘制先画到一块内存位图上，画完后再一次性复制到窗口。屏幕上看不到中间过程，闪烁自然消失。实例里的动画工程基本都是这个套路：

void CMyView::OnPaint() { CPaintDC dc(this); // 窗口的 DC CRect rc; GetClientRect(&rc); CDC memDC; memDC.CreateCompatibleDC(&dc); // 创建内存 DC CBitmap bmp; bmp.CreateCompatibleBitmap(&dc, rc.Width(), rc.Height()); CBitmap* pOldBmp = memDC.SelectObject(&bmp); // 位图选入内存 DC // 所有绘制都在 memDC 上进行 memDC.FillSolidRect(rc, RGB(255, 255, 255)); memDC.MoveTo(0, 0); memDC.LineTo(rc.Width(), rc.Height()); // 一次性把内存画面拷到窗口 dc.BitBlt(0, 0, rc.Width(), rc.Height(), &memDC, 0, 0, SRCCOPY); memDC.SelectObject(pOldBmp); // 恢复，防止位图未释放 }

这里最容易翻车的点有两个。一是 CreateCompatibleBitmap 的尺寸不能是 0：窗口被完全最小化时客户区尺寸是 0，CreateCompatibleBitmap 会失败，后面 BitBlt 也画不出内容。稳妥的做法是在创建位图前先判断 rc.Width() 和 rc.Height() 是否大于 0。二是位图的释放依赖 SelectObject 恢复旧位图——如果遗漏这一行，CBitmap 析构时可能因为还选在 DC 里而释放不干净。

BitBlt 的五个参数是目标位置和尺寸（左上角 x、y、宽、高）、源 DC、源位置（0,0）、光栅操作码。SRCCOPY 表示直接覆盖复制，这是最常见的模式。做逐帧动画时如果背景复杂，可以改用 2000 运算法则配合透明色，但实例里的简单图形用 SRCCOPY 足够。

3.4 GDI 对象管理：选入、恢复、删除三部曲

GDI 对象包括画笔、画刷、字体、位图、区域。它们的泄漏不像内存泄漏那样会直接报错，而是慢慢耗尽系统资源，表现是运行十几分钟后绘图失效、界面卡顿、甚至整个系统变慢。这是 MFC 绘图程序最阴性的问题，排查时得靠任务管理器的 GDI 对象计数。

正确的生命周期管理是三部曲：SelectObject 选入 → 用返回值保存旧对象 → 用完恢复旧对象并让临时对象析构或手动 DeleteObject。栈对象自动析构，堆对象必须手动 delete。

// 推荐：栈对象 + 自动析构 CPen pen(PS_SOLID, 1, RGB(255, 0, 0)); CPen* pOld = pDC->SelectObject(&pen); // 绘制... pDC->SelectObject(pOld); // 恢复 // 函数结束，pen 自动析构

// 不推荐：new 了不 delete，这就是泄漏源头 CPen* pPen = new CPen(PS_SOLID, 1, RGB(255, 0, 0)); pDC->SelectObject(pPen); // 画完忘了恢复、忘了 delete，每次刷新泄漏一个 GDI 对象

我自己的习惯是能不用 new 就不用 new，所有画笔画刷一律声明成栈对象。只有跨函数长期持有的字体、位图才放堆里，而且一定在析构函数里统一清理。如果你在拆实例时看到 OnDraw 里全是 new 出来的 GDI 对象，先别抄，先把它们改成栈对象再说。

4. 控件与消息实战：按钮、鼠标画线与定时器的三种接线方式

图形绘制解决的是「画什么」，界面编程解决的是「怎么交互」。这一章把实例包里的三类交互手段拆开：控件消息、鼠标消息、定时器消息。它们的共同底层是第 2 章讲过的消息映射表。

4.1 控件消息与对话框：按钮点击如何进到消息映射

对话框程序里最常见的需求是：用户在一个编辑框里输入数字，点按钮，程序根据数字画图。控件的消息处理函数要用 ON_BN_CLICKED 宏绑定到按钮的 ID 上。

BEGIN_MESSAGE_MAP(CMyDlg, CDialogEx) ON_BN_CLICKED(IDC_BTN_DRAW, &CMyDlg::OnBnClickedBtnDraw) END_MESSAGE_MAP()

void CMyDlg::OnBnClickedBtnDraw() { CString strText; GetDlgItemText(IDC_EDIT_COUNT, strText); // 读取编辑框文本 int nCount = _ttoi(strText); // CString 转 int，兼容 Unicode if (nCount <= 0 || nCount > 100) { MessageBox(_T("请输入 1 到 100 之间的数字"), _T("提示"), MB_OK); return; } CClientDC dc(this); // 主动绘制用 CClientDC CRect rc; GetClientRect(&rc); dc.FillSolidRect(rc, RGB(255, 255, 255)); for (int i = 0; i < nCount; i++) { int x = rand() % rc.Width(); int y = rand() % rc.Height(); dc.SetPixel(x, y, RGB(0, 0, 255)); } }

这段代码有三个接线细节。一是控件 ID 必须和资源文件里的一致，IDC_EDIT_COUNT 一旦在 .rc 里改了，消息映射里的名字没同步，消息就接不上。二是 GetDlgItemText 是手动取值的方式，实例里有的工程用 DDX 数据交换（控件和成员变量自动同步），两种风格要辨别清楚：DDX 适合固定控件，手动 GetDlgItem 适合动态生成长度的逻辑。三是 _ttoi 是安全建议：直接用 atoi 处理 Unicode 工程里的 CString 会因字符集不匹配而转换失败，这是第 5 章会细说的坑。

参数校验这段不是多余的。MFC 程序对非法输入的处理比命令行工具敏感得多，负数或超大的 nCount 会导致 for 循环长时间运行，界面假死几分钟，你很难跟用户解释是随机数画慢了。

4.2 鼠标画线：从按下到抬起，坐标怎么存

鼠标绘制是交互的第二个重头戏。实现思路是 WM_LBUTTONDOWN 记录起点，WM_LBUTTONUP 画终点。很多初学实例只做到这一层，但完整工程还会涉及 SetCapture 和点集存储。

// 头文件里声明成员变量 CPoint m_ptStart; // 鼠标按下时的起点 // 按下时记录起点并捕获鼠标 void CMyView::OnLButtonDown(UINT nFlags, CPoint point) { m_ptStart = point; SetCapture(); // 捕获鼠标，窗口外抬起也能收到消息 CView::OnLButtonDown(nFlags, point); } // 抬起时画线 void CMyView::OnLButtonUp(UINT nFlags, CPoint point) { if (GetCapture() == this) // 确认捕获者是自己 { CClientDC dc(this); dc.MoveTo(m_ptStart); dc.LineTo(point); // 存线段到数组，供重绘时恢复 m_LineArray.Add(m_ptStart); m_LineArray.Add(point); ReleaseCapture(); // 释放捕获 } CView::OnLButtonUp(nFlags, point); }

这里的 point 参数已经是客户区坐标，直接用就行。但如果视图带滚动条，point 还需要换算成文档坐标：加回滚动偏移量point += GetScrollPosition()，否则画在滚动后的视图上位置会错位。

画完线就完事了吗？不是。窗口一旦被遮挡再显示，WM_PAINT 触发时 OnDraw 会被调用，而你画在客户区的内容不会自动保留——这是 MFC 绘图的经典认知：所有绘制都是易失的，想持久显示必须把图形数据存起来，在 OnDraw 里重放。实例里一般用 CArray 或 CPtrArray 存线段端点，OnDraw 里遍历数组重新画。这个「数据与绘制分离」的模型，是鼠标绘图工程从玩具走向工具的分水岭。

4.3 定时器驱动的界面刷新：SetTimer 与 OnTimer 的边界

动画、时钟、进度条，都靠 WM_TIMER 消息驱动。SetTimer 创建定时器，OnTimer 处理触发，KillTimer 销毁。对话框程序里这段代码到处可见：

BOOL CMyDlg::OnInitDialog() { CDialogEx::OnInitDialog(); SetTimer(1, 100, NULL); // 定时器 ID=1，每 100ms 触发一次 return TRUE; } void CMyDlg::OnTimer(UINT_PTR nIDEvent) { if (nIDEvent == 1) { m_nTick++; // 计数累积 CClientDC dc(this); int x = m_nTick % 300; // 目标横坐标随时间变化 dc.FillSolidRect(CRect(0, 0, 400, 60), RGB(255, 255, 255)); dc.Rectangle(x, 20, x + 40, 50); // 画一个移动的方块 InvalidateRect(NULL, TRUE); // 标记整个客户区需要重绘 } CDialogEx::OnTimer(nIDEvent); } void CMyDlg::OnDestroy() { KillTimer(1); // 窗口销毁前必须停掉 CDialogEx::OnDestroy(); }

三个参数按顺序是：定时器 ID、间隔毫秒、回调函数（NULL 表示用 OnTimer）。ID 用来区分多个定时器，OnTimer 里必须判断 nIDEvent 分支处理。上面这段代码里 FillSolidRect 加 Rectangle 组合其实有点浪费，因为定时器每 100ms 触发一次，每次都重画整个窗口，效率一般。更合理的做法是只 InvalidateRect 一个小的区域，缩小重绘范围。

WM_TIMER 有个容易被忽略的边界：它的优先级低于很多其他消息。用户按住窗口标题栏拖动、系统弹出菜单时，WM_TIMER 可能会延迟甚至丢失。所以定时器里只适合放轻量级 UI 更新，不能依赖它做精确计时。真要精确到毫秒级的，得用多媒体定时器，但那会回调在独立线程，直接操作 UI 可能引发线程冲突，实例包里不涉及，你自己改造时再留意。

提示：OnTimer 里不要写耗时操作，比如访问数据库、读大文件。消息积压会让界面假死，看起来像「程序卡了」。

5. 编译与运行排障：五个高频报错的根因与止血方案

这一章是实操里最值钱的部分。MFC 工程的报错规律性很强，同一个错误往往对应同一个根因。下面五条来自源码包在各机器上跑出来的血泪经验，按出现频率排序。

5.1 找不到 afxwin.h：MFC 组件没装全

现象：新建或打开实例工程后编译，第一行就报 fatal error C1083: Cannot open include file: 'afxwin.h'，后面还跟着一长串找不到 MFC 头文件的错误。

原因：VS 安装时没勾选「适用于桌面的 MFC」组件。也有可能是工程模板选错，建成了 Win32 控制台程序，却强行包含 MFC 头文件。

解决：打开 VS 安装器，修改安装，勾选「适用于桌面的 MFC」和「C++ MFC 生成工具」，更新完成后重启 VS。如果用的是控制台工程，重新用「MFC 应用程序」向导建工程，再把实例里的 .cpp 和 .h 文件添加进去。检查工程里是否已经包含了预编译头，正常 MFC 工程在 pch.h 里会有#include <afxwin.h>，没有这行就要手动加。

5.2 Debug 能跑、双击 exe 报缺 DLL：链接方式没选对

现象：开发机上按 F5 一切正常，把 exe 拷到另一台干净机器，双击报「无法启动此程序，因为计算机中丢失 mfc140ud.dll」。

原因：工程属性里 MFC 的使用方式是「使用共享 DLL」，Debug 版依赖调试版 MFC 运行库，而运行库不会跟随系统分发。共享 DLL 模式发布的程序必须带上对应版本的 MFC DLL。

解决：发布时切到 Release 配置，把项目属性 → 常规 → MFC 的使用改成「在静态库中使用 MFC」。这样 MFC 代码直接编进 exe，不再依赖外部 DLL，换来的是 exe 体积明显变大，但换机器运行几乎不出问题。注意 Release 缺的是 mfc140u.dll 而非 mfc140ud.dll，名字里那个 d 就是 Debug 的标记。

5.3 窗口拉伸就闪烁花屏：擦除与重绘的配合问题

现象：画图程序单帧显示正常，但一拖动窗口边缘调整大小，画面剧烈闪烁，偶尔出现残影。

原因：WM_PAINT 触发前，系统先往客户区填充背景色，把旧内容擦掉，然后才调用绘图函数画新内容。擦和画之间的空档就表现为闪烁。更糟的是绘图函数里如果忘了先填充背景，会看到黑块或残影残留。

解决：按第 3 章的双缓冲方案重写 OnPaint，并让 OnEraseBkgnd 直接返回 TRUE，告诉系统「背景不用你擦，我已经在内存画布里处理了」：

BOOL CMyView::OnEraseBkgnd(CDC* /*pDC*/) { return TRUE; // 禁止系统擦除背景 }

这条改动配合双缓冲，闪烁能消掉九成。但注意 OnEraseBkgnd 返回 TRUE 意味着你承诺自己处理了背景，双缓冲的内存 DC 里必须先 FillSolidRect 把底填干净，否则画面上会残留上一次的图形痕迹，那是另一种「拖影」。

5.4 GDI 对象数持续上涨：谁在泄漏

现象：程序运行十几分钟，界面越来越卡。打开任务管理器 → 详细信息 → 右键表头选「GDI 对象」，能看到这个数字从 100 多涨到几千甚至上万，且不回落。

原因：OnDraw 或按钮处理函数里 new 了 CPen、CBrush、CBitmap，但没调用 DeleteObject。每次窗口刷新就泄漏几个对象，系统 GDI 资源总量有限，耗尽后绘图函数静默失败——不报错，但画面逐渐消失。

解决：回到第 3 章的 GDI 对象管理三部曲。能定义成栈对象就不 new；必须 new 的，确保在函数结束前 DeleteObject；SelectObject 的返回值必须接收，画完恢复。我排查泄漏的办法很笨但有效：运行程序，每隔一分钟看一次 GDI 对象数，如果曲线在上升，就二分注释 OnDraw 里的绘制段，缩小到具体是哪一段泄漏。

5.5 Unicode 工程里中文乱码：字符集与 _T 宏

现象：界面按钮、MessageBox、标题栏上的中文显示成乱码；或者代码里写MessageBox("绘制完成")直接编译报错，提示无法从 const char 转换为 LPCTSTR。

原因：现在 VS 新建的 MFC 工程默认字符集是 Unicode，所有 Win32 API 的字符串参数都是宽字符版本。代码里用裸的双引号字符串是窄字符，类型对不上。

解决：字符串字面量一律套_T()宏，让它在 ASCII 工程里展开成窄字符、在 Unicode 工程里展开成宽字符。比如MessageBox(_T("绘制完成"))。源文件保存时用 UTF-8 with BOM 编码，避免编译器因为编码猜错产生乱码。旧代码里 char 数组和 CString 混用的地方，全部统一成 CString 或 LPCTSTR 传递，不要在这两个类型之间裸转换。

6. 把源码包改造成自己的工具：三条验证路线

下载回来的 MFC 实例，最终目的是被你改造、为你所用。我拿到一份新实例，不急着读代码，先按固定顺序验证三件事，能快速判断这份资源值不值得继续投入时间。

第一件事是编译零警告通过。实例包里有多个工程时，逐个工程确认 Debug x86 和 x64 两个配置都能编译过，且输出窗口没有 warning。MFC 的 warning 和业务代码的 warning 性质不同，它往往暗示字符集不匹配或者 GDI 对象使用不当，忽略掉迟早会变成运行期故障。

第二件事是每个交互点都点一遍。按钮、菜单、鼠标拖动、定时器刷新，一个不漏。重点看窗口拉伸时闪不闪、最小化再恢复后图形还在不在、连续快速点击按钮会不会界面假死。这三关过了，绘图和界面部分基本是健康的。

第三件事是开着任务管理器的 GDI 对象列，跑 10 分钟看曲线。稳定在初始值上下小幅波动是正常的，只涨不降就是泄漏。这一步能劝退不少「看起来功能齐全、实际上经不起用」的包装工程。

验证通过之后，我一般会把实例里最通用的那段双缓冲绘制模板单独抽出来，存成自己的代码片段：

void CMyView::OnPaint() { CPaintDC dc(this); CRect rc; GetClientRect(&rc); if (rc.Width() <= 0 || rc.Height() <= 0) return; // 窗口最小化时不画 CDC memDC; memDC.CreateCompatibleDC(&dc); CBitmap bmp; bmp.CreateCompatibleBitmap(&dc, rc.Width(), rc.Height()); CBitmap* pOld = memDC.SelectObject(&bmp); // 在这里填你的绘制内容 memDC.FillSolidRect(rc, RGB(255, 255, 255)); // 画线、画矩形、画文字... dc.BitBlt(0, 0, rc.Width(), rc.Height(), &memDC, 0, 0, SRCCOPY); memDC.SelectObject(pOld); }

这套模板配上 OnEraseBkgnd 返回 TRUE，是我画任何动态图形的基本盘。从那以后，我每次从网上下 MFC 图形或界面相关的实例包，都会强制走一遍「编译零警告 → 全交互点摸底 → 盯 GDI 对象曲线」的流程。这个顺序帮我避开过很多看起来光鲜、一跑就崩的坑货，也让我想起了刚学 MFC 时对着花屏和乱码整夜翻文档的自己。希望帮到你。

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