企业官网建设流程全解析

简介：一份面向C/C++基础较好、正准备转入Windows界面开发的初学者的MFC入门学习笔记。文档从“如何学好VC”谈起，先强调通过字符界面程序夯实C++功底，再系统梳理Windows消息机制：消息的组成、窗口过程、默认处理、消息队列与窗口句柄等，并对比16位与32位系统的多任务差异。同时说明MFC借助C++封装、派生、虚拟特性带来的开发优势，以及消息映射用宏定义分派消息的基本实现思路。全文以1个doc文档承载，压缩包约521KB，篇幅精简但结构完整，没有冗杂示例代码，更适合作为提纲式导读。已有729人学习浏览，尤其适合作为自学VC++6.0 MFC的第一份入门材料，也可用于快速理解消息驱动与MFC框架核心原理。

1. MFC入门：别急着拖控件，先把消息机制和 C++ 底子打牢

很多人接触 VC++ 6.0 的第一反应是打开 ApplicationWizard 生成一个对话框工程，然后往界面上拖按钮，但真正在 MFC 入门阶段拉开差距的，往往不是拖控件的手速，而是对 Windows 消息机制和 C++ 对象模型的理解深度。我拆这份入门资料时最有感触的一点是：它没有一上来贴代码，而是先用一整章讲清楚“消息是什么、消息从哪来、没处理的消息去哪了”，这些恰恰是后面理解消息映射、编写窗口过程、排查界面不刷新等问题的地基。这份材料适合两类人：一类是有 C/C++ 语法基础、正要转向 Windows 界面开发的初学者；另一类是写过几年业务代码、但始终觉得 MFC 是黑匣子、想补原理的开发者。按它的路线走，核心收益是把“照着书抄”变成“知道为什么这么写”。

2. 理解 Windows 消息机制：消息、句柄与消息队列

2.1 消息的组成：UINT 名称与两个参数

Windows 是消息驱动的操作系统，这一点和传统顺序执行的字符界面程序完全不同。一个消息由三部分组成：消息名称（UINT 类型），以及 WPARAM、LPARAM 两个参数。消息名称决定“发生了什么”，比如鼠标按下是 WM_LBUTTONDOWN，窗口需要重绘是 WM_PAINT，菜单被选中是 WM_COMMAND。两个参数则携带上下文信息，比如鼠标消息里 WPARAM 可能存放按键状态，LPARAM 的低位和高位分别存放鼠标的 x、y 坐标。

以菜单消息为例，当用户点击菜单项后，系统会发送 WM_COMMAND 到窗口，这时 WPARAM 的高字（HIWORD(wParam)）是命令 ID 号，对菜单来说就是菜单项的 ID。只要在资源编辑器里给菜单项分配了 ID，程序里就能用这个 ID 判断用户点了哪个菜。除了系统预定义消息，你还可以用 WM_USER 以上的数值自定义消息，用来在窗口之间发送通知或传递数据。这个能力在自绘控件、子窗口回调场景里非常常用。

// 一个消息的基本结构，伪代码形式 struct tagMSG { HWND hwnd; // 接收消息的窗口句柄 UINT message; // 消息名称，如 WM_PAINT、WM_COMMAND WPARAM wParam; // 附加信息，语义随消息类型变化 LPARAM lParam; // 附加信息，语义随消息类型变化 DWORD time; // 消息产生时间 POINT pt; // 鼠标位置 };

注意 WPARAM 和 LPARAM 在 32 位系统里都是 4 字节，它们的语义完全由具体消息决定。比如 WM_COMMAND 的 wParam 高字是命令 ID、低字是发送通知码；WM_LBUTTONDOWN 的 lParam 低字是 x 坐标、高字是 y 坐标。不要死记硬背每个消息的参数含义，而是要在用到某条消息时直接查联机帮助，时间长了自然就记住了。这份资料里反复强调“不翻书、多用 Help Online”，其实就是在训练你建立查证习惯。

2.2 窗口过程：谁收到消息，没处理的消息去哪了

消息必须由一个窗口接收。每个窗口都有一个关联的窗口过程（WNDPROC），窗口过程本质上是一个回调函数，负责对收到的消息做分析、分类、处理。你可以用 switch 语句把感兴趣的消息挑出来写处理逻辑，不感兴趣的交给默认窗口过程处理。这里的关键认知是：窗口过程不是你自己主动调用的，而是系统在消息到达时自动回调的，你只负责注册这个过程的入口地址。

// 窗口过程的标准骨架，伪代码 LONG YourWndProc(HWND hWnd, UINT uMessageType, WPARAM wParam, LPARAM lParam) { switch (uMessageType) { case WM_PAINT: // 窗口需要重新绘制时在这里输出 DoYourWindow(hWnd); break; case WM_LBUTTONDOWN: // 鼠标左键按下时在这里处理 DoYourWork(hWnd, LOWORD(lParam), HIWORD(lParam)); break; default: // 其余消息交给系统默认过程 return CallDefaultWndProc(hWnd, uMessageType, wParam, lParam); } return 0; }

这里有个重要细节：默认窗口过程是系统提供的，它负责处理那些你不关心的消息，比如窗口拖动时的 WM_MOVE、窗口大小变化时的 WM_SIZE、点击关闭按钮时的 WM_CLOSE。正因为它存在，开发者才能只关注和自己业务相关的消息，而不必为每一种系统行为写处理代码。举例来说，窗口被拖动时系统会连续发送多条消息，你完全不用管，系统默认过程会把窗口位置和外观都维护好。

2.3 窗口句柄与消息队列：系统怎么找到接收者

说到消息就不能不提窗口句柄 HWND。系统通过句柄在整个系统中唯一标识一个窗口，发送消息时必须指定句柄，以此表明消息由哪个窗口接收。两个窗口可以共用同一个窗口过程代码，但句柄不同，消息就会被正确分发到各自的目标。你可以把句柄理解为窗口的身份证号，静态成员函数或全局函数通过它才能定位到具体窗口实例。

消息机制的核心是队列。系统维护一个或多个消息队列，所有产生的消息都被放入或插入队列中。每个运行的程序有自己的消息循环，循环从自己的队列中取出属于本程序的消息，根据消息里的接收句柄调用对应的窗口过程。当程序没有消息时，getMessage 不会返回，程序让出 CPU 控制权，这也是 Windows 能同时运行多个任务的基础。

// 消息循环的标准写法，伪代码 while (GetMessage(&msg, NULL, 0, 0)) { if (msg.message == WM_QUIT) break; TranslateMessage(&msg); // 将虚拟键消息转换为字符消息 DispatchMessage(&msg); // 把消息分发给窗口过程 }

GetMessage 在队列为空时阻塞等待，不占用 CPU 时间；TranslateMessage 负责把键盘的按下/抬起消息翻译成字符消息；DispatchMessage 才真正调用窗口过程。在 16 位系统里只有一个全局消息队列，系统必须等当前任务处理完消息才能发送下一条，任务陷入死循环整个系统就卡死，这被称为协同式多任务。32 位系统中每个程序都有独立的队列，系统可以在各队列间切换而不必等待当前程序完成，这就是抢占式多任务。MFC 之所以能在全局上简化开发，正是因为它把这套窗口过程、消息循环都封装进了框架的底层，但也正因为封装，很多人反而搞不清消息到底是怎么流转的。

3. MFC 消息映射：从宏展开到消息处理函数

3.1 MFC 为什么不用虚函数处理消息

如果 MFC 给每个类封装几十甚至上百个虚函数来处理消息，那每个派生类都要承载巨大的虚函数表，而且 C++ 虚函数机制对消息这种“多对一”的分发场景并不友好——你只想处理两三个消息，却要继承一个带几十个虚函数的基类。MFC 选择了消息映射（Message Map）方案：用宏在类内部声明一张静态映射表，把消息编号和对应的处理函数指针关联起来，查找时按表扫描，命中就调用，未命中就交给基类的映射表继续查。这样既保持了 C++ 的封装和派生特性，又避免了虚函数表的开销和混乱。

要理解 MFC 的消息映射，必须回到上一章讲的窗口过程。任何一个 CWnd 派生类创建的窗口，其窗口过程入口都是相同的，MFC 在这个公共入口里拿到消息后，会查找当前对象所属类的消息映射表，找到就调用对应的成员函数，找不到就沿继承链向上逐级查找基类的映射表，最终没找到就交给 DefWindowProc。

3.2 宏展开：看穿消息映射的本质

资料里给了一段非常直观的展开过程。先看源码中的消息映射声明：

BEGIN_MESSAGE_MAP(CMainFrame, CFrameWnd) //{{AFX_MSG_MAP(CMainFrame) ON_WM_CREATE() // 处理 WM_CREATE 消息 //}}AFX_MSG_MAP ON_COMMAND(ID_FONT_DROPDOWN, DoNothing) // 处理菜单命令 END_MESSAGE_MAP()

这段代码经过预处理后，本质上被展开成一个形如 switch 的分发过程，虽然实际实现比这复杂，但逻辑等价于：

// 经过展开后的等价逻辑，用于示意消息映射机制 LRESULT CMainFrame::WindowProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam) { switch (message) { case WM_CREATE: // ON_WM_CREATE 宏展开后的调用 return OnCreate(reinterpret_cast<LPCREATESTRUCT>(lParam)); case WM_COMMAND: // ON_COMMAND 宏展开后的调用 if (HIWORD(wParam) == ID_FONT_DROPDOWN) { DoNothing(); return 0; } break; default: break; } // 继续查基类映射表，最终交给 DefWindowProc return CFrameWnd::WindowProc(hWnd, message, wParam, lParam); }

注意几个细节：ON_WM_CREATE 这种宏是预定义的消息映射宏，它会自动把 WM_CREATE 消息与 OnCreate 成员函数绑定，参数顺序和类型都由宏已经规定好；ON_COMMAND 则是命令消息宏，需要显式给出命令 ID 和处理函数名，它拦截 WM_COMMAND 消息，然后比较 wParam 高字中的 ID 是否匹配。窗口过程是所有该类的实例共享的，只要这个类的对象创建了窗口，消息就会被路由到同一个入口，再通过 this 指针找到具体的对象实例，调用对应的成员函数。这就是 MFC 能把系统消息“翻译”成 C++ 成员函数调用的核心机制。

3.3 消息分类与 ClassWizard 的维护约定

MFC 消息分三类。标准 Windows 消息如 WM_CREATE、WM_PAINT、WM_TIMER，由窗口类和视图类处理；命令消息 WM_COMMAND，来自菜单、工具栏按钮、快捷键，由框架、文档、视图、窗口等按路由顺序传递；控件通知消息，由子控件发送给父窗口，如按钮点击的 BN_CLICKED。不同消息的映射宏写法不同，一定要区分。

ClassWizard 是 VC++ 6.0 里维护消息映射的可视化工具，它会把自动生成的映射条目放在//{{AFX_MSG_MAP和//}}AFX_MSG_MAP注释块中间。这个区间是 ClassWizard 的“自留地”，手动在区间外添加映射是安全的，但千万不要手工修改区间内的内容，否则 ClassWizard 可能识别失败，导致以后打开工程时消息映射被覆盖或丢失。

// 手动添加一个自定义消息的处理入口 // 常见做法是在类声明中加入 afx_msg 成员函数声明 class CMainFrame : public CFrameWnd { // 处理自定义消息 WM_USER + 100 afx_msg LRESULT OnMyMessage(WPARAM wParam, LPARAM lParam); DECLARE_MESSAGE_MAP() }; // 在类实现文件中 BEGIN_MESSAGE_MAP(CMainFrame, CFrameWnd) //{{AFX_MSG_MAP(CMainFrame) ON_WM_CREATE() //}}AFX_MSG_MAP ON_MESSAGE(WM_USER + 100, OnMyMessage) // 手工添加在区间外 END_MESSAGE_MAP()

自定义消息用 ON_MESSAGE 宏关联，处理函数签名固定为LRESULT (WPARAM, LPARAM)。写到这里要特别提醒：消息映射表中不能出现两个相同的消息入口，也不要把 ON_COMMAND 和 ON_MESSAGE 混用，否则查找时会命中错误的分支，这种错误不会报编译错，运行期表现也很隐蔽，属于典型的难排查问题。

4. MFC 入门避坑排查：消息映射失效、DC 对象泄漏与 CString 断言

4.1 消息处理函数不执行

现象：在 ClassWizard 里添加了 WM_TIMER 或 ON_COMMAND 的处理函数，编译链接都正常，但程序运行后断点进不去，消息好像被系统直接吞了。

原因：最常见的有三种。第一种，处理函数写在消息映射表里，但宏名拼错，比如把 ON_WM_TIMER 写成 ON_MESSAGE(WM_TIMER, ...)，导致映射表中缺少条目；第二种，类向导把条目放在//}}AFX_MSG_MAP区间内，但你手工编辑过这块，破坏了//{{和//}}的配对，ClassWizard 无法识别因此没有真正写入映射条；第三种，命令消息 ON_COMMAND 的 ID 与资源中菜单或按钮的 ID 不一致，用户操作时系统发送的是另一个数字。

解决：先在 BEGIN_MESSAGE_MAP 里搜索对应宏是否存在，再检查 ID 是否与资源编辑器里的一致。最有效的排查手段是在窗口过程入口临时加一个断点，看消息是否到达了窗口。如果到达了但没进处理函数，问题一定在映射表；如果没到达，就要检查消息来源，比如 WM_TIMER 是否真的用 SetTimer 设置了。

4.2 DC 中保存了无效的 GUI 对象指针导致绘图异常

现象：程序运行一段时间后，窗口重绘时出现花屏，或者拖动窗口时突然崩溃，Debug 版本弹出 ASSERT 失败，指向 SelectObject 相关的断言。

原因：这是 GUI 对象选入 DC 后没有正确恢复导致的。常见流程是创建了画笔、刷子，SelectObject 选入 DC，然后循环里反复创建新对象而没有 DeleteObject 旧的，也没有把原来的对象恢复回去。当局部对象生命周期结束后被销毁，但 DC 中还持有指向它的指针，下次绘图时继续引用就成了野指针。

解决：严格遵守“创建→选入→保存原对象→使用→恢复原对象→销毁”的顺序。每次使用完临时 GUI 对象后，立即 SelectObject 恢复原来的对象，再让临时对象销毁。

// 规范的画笔使用方式，摘自资料中的示例并补充细节 CPen pen1, pen2; pen1.CreatePen(PS_SOLID, 2, RGB(128, 128, 128)); // 创建实线画笔 pen2.CreatePen(PS_SOLID, 2, RGB(128, 128, 0)); // 创建另一支画笔 CPen* pPenOld = (CPen*)pDC->SelectObject(&pen1); // 选入 pen1，保存原画笔 // 用 pen1 绘制... pDC->SelectObject(&pen2); // 切换到 pen2，不需要再保存 // 用 pen2 绘制... pen1.DeleteObject(); // 销毁 pen1 pen1.CreatePen(PS_DASH, 1, RGB(0, 0, 0)); // 重建为虚线画笔 pDC->SelectObject(&pen1); // 再次选入 // 用虚线绘制... pDC->SelectObject(pPenOld); // 最后恢复原始画笔

注意一个细节：第二次 SelectObject(&pen2) 之前理论上也应该保存 pen2 之前的旧对象，但在你马上还要换回 pen1 的场景下，只需要保证最终恢复最开始保存的 pPenOld 就行。核心原则是 DC 里不能遗留任何指向栈对象的指针，且两次创建同一个对象前先销毁。

4.3 CString 格式化时崩溃或断言

现象：调用 CString::Format 时，Debug 版本弹出断言，提示“字符串溢出”或“无效的格式化字符串”，Release 版本直接非法访问。

原因：CString 的 Format 和 sprintf 类似，不检查缓冲区边界，也不检查参数个数。常见写法是用str.Format("%s", 整数变量)或者格式串中写了%s但参数实际是CString对象而不是LPCSTR指针。第二种情况在 CString 重载了operator LPCSTR之后看起来能编译通过，但某些重载决议下会传递 this 指针而不是数据指针，运行期表现很诡异。

解决：格式化字符串和参数类型严格对应，传 CString 时显式转型为(LPCTSTR)str或者直接调用它的 GetString()。另外注意%d和%u在 32 位下对应 int 和 unsigned int，长整数要用%ld，不要混用。

// 错误写法，编译期可能没警告，运行期容易断言 CString value = GetSomeText(); CString message; message.Format("当前值: %s", value); // 某些重载决议下会出错 // 正确写法 message.Format("当前值: %s", (LPCTSTR)value); message.Format("数值: %d", 42);

这里还有一坑：CString::Format 在 Unicode 工程下格式串要写宽字符版本，VC++ 6.0 默认工程是 ANSI，但如果你改了字符集设置，格式串中的中文文本必须用_T()包裹，否则中文变乱码。如果你用 DT_END_ELLIPSIS 与 DT_MODIFYSTRING 组合调用 DrawText，官方文档中明确注明可能修改传入的字符串并触发 CString 重载的断言，这种场景下宁可先把文本复制到独立缓冲区里。

4.4 画笔宽度为 2 时虚线变实线

现象：调用 CreatePen(PS_DASH, 2, RGB(0,0,0)) 创建虚线画笔，画出来却是一条实线。

原因：PS_DASH、PS_DOT、PS_DASHDOT 等线型风格在设备单位下只对宽度为 1 的画笔有效。宽度大于 1 时系统会忽略线型而使用实线绘制。这不是 MFC 或驱动的 bug，而是 GDI 的规则。

解决：需要虚线效果时把宽度保持为 1。如果确实需要又宽又虚的线，常见做法是使用几何画笔（ExtCreatePen），或者放弃线型改为手工按长度间隔绘制线段。对入门阶段来说，记住“虚线必用 1 号笔”就够了。

5. GUI 对象与 DC 绘图实战：创建、选入、恢复、销毁的完整套路

5.1 DC 是什么，GUI 对象为什么必须选入 DC

DC（Device Context，设备环境）是一个抽象绘图环境，它可能对应屏幕、打印机、内存位图或其它输出设备。同一个绘图代码，只需要更换 DC，就能在不同的设备上输出相同的结果，这正是 Windows 设备无关性的核心体现。MFC 把 DC 封装成 CDC 类，你拿到的 CDC* 可能是屏幕环境、打印预览环境，也可能只是内存环境，但绘图函数调用完全一致。

要绘图必须有三样东西就位：一个合法的 DC，一支画笔（画线用），一把刷子（填充用），以及必要的字体和位图。创建好的 GUI 对象不能直接使用，必须调用 SelectObject 把它选入 DC，绘图函数才会使用当前 DC 中的对象进行绘制。这里也解释了为什么“创建了对象但画面没变化”——对象没选入 DC，或者选入的是另一个 DC。

5.2 在 OnDraw 中输出文字与创建字体

OnDraw 是 CView 派生类中最重要的绘图入口，窗口需要重绘时它会被自动调用。传入的 CDC* 参数在不同的调用场景里对应不同的设备环境：屏幕显示时是窗口 DC，打印时是打印机 DC，打印预览时是 CPreviewDC。所以只要在 OnDraw 里写一份绘制代码，屏幕显示、打印预览、打印机输出三处同时生效，所见即所得。这与传统的直接在 WM_PAINT 里绘图方式相比，省掉了大量重复代码。

void CMyView::OnDraw(CDC* pDC) { CString strText = _T("Hello, MFC"); CRect rectClient; GetClientRect(&rectClient); // 设置文字颜色与背景模式 pDC->SetTextColor(RGB(0, 0, 255)); pDC->SetBkMode(TRANSPARENT); // 透明背景，避免黑色底色块 // 在客户区居中输出单行文字 pDC->DrawText(strText, &rectClient, DT_CENTER | DT_VCENTER | DT_SINGLELINE); }

DrawText 相比 TextOut 灵活得多。TextOut 只能输出单行文本，DrawText 可以指定一个矩形区域并在其中输出单行或多行文本，支持 DT_CENTER、DT_RIGHT、DT_VCENTER、DT_WORDBREAK 等样式组合。注意 DT_VCENTER 必须和 DT_SINGLELINE 一起使用，否则垂直居中不生效。DT_CALCRECT 只计算文本所需要占用的矩形大小而不绘制，这个特性在做自绘控件、动态布局时非常有用。

字体创建则要复杂一些。CFont 可以通过 CreateFontIndirect(LOGFONT) 或直接 CreateFont 创建。LOGFONT 结构体里的字段很多，常用的关键参数包括：lfHeight 字体高度（逻辑单位），0 表示使用系统默认高度；lfWeight 字体粗细，FW_BOLD 为 700、FW_NORMAL 为 400；lfItalic、lfUnderline 控制斜体和下划线；lfCharSet 在中文环境下必须设成 GB2312_CHARSET 或 DEFAULT_CHARSET，否则中文字符显示为乱码或方框；lfFaceName 指定字体名，如“宋体”“Arial”。

// 创建一支 24 磅大小的粗体宋体字体 CFont font; LOGFONT lf = {0}; lf.lfHeight = -24; // 负值表示按字符高度计算 lf.lfWeight = FW_BOLD; // 粗体 lf.lfCharSet = GB2312_CHARSET; // 中文环境必须设 strcpy(lf.lfFaceName, "宋体"); font.CreateFontIndirect(&lf); CFont* pOldFont = pDC->SelectObject(&font); // 选入字体 pDC->TextOut(100, 100, _T("这是一行测试文字")); pDC->SelectObject(pOldFont); // 恢复字体

注意 lfHeight 用负值更稳妥。正值表示的是“字符高度加上行距”的完整行高，负值表示按字符本身的像素高度匹配，后者更符合直觉，也更容易在不同 DPI 下保持一致。创建完字体同样需要选入 DC，用完后恢复。表面看这只是准备工作，但真正的坑往往藏在字符集不一致和恢复遗漏这两处。

5.3 画笔、刷子与库存对象的配合

绘图时画点用 SetPixel，效率很低，连续画几千个点就能感觉到卡顿，只适合像素级操作。画线、画矩形、画圆用的是系统当前 DC 中的画笔和刷子，画笔决定轮廓、刷子决定填充。创建实线画笔用 PS_SOLID，想要虚线、点线、点划线时宽度必须为 1 这个限制前面已经提过，这里不再重复。刷子除了颜色，还能选择网格样式，或者用 8x8 位图创建自定义模板刷子，填充时系统会用位图平铺整个区域。

还有一种更省事的方案是使用库存对象。系统中预制了一批固定颜色刷子、画笔和基本字体，通过 CDC::SelectStockObject 直接选入，不需要创建，也不会被销毁。它们在 DC 中留下是安全的，因此在恢复 DC 原始状态时也常被用来做“兜底”恢复：

// 用库存对象清理 DC 状态 pDC->SelectStockObject(NULL_BRUSH); // 空心刷子，填充区域内部不涂色 pDC->SelectStockObject(BLACK_PEN); // 黑色实线画笔 pDC->SelectStockObject(SYSTEM_FONT); // 恢复系统默认字体

当你在自绘控件的 OnPaint 里画了一堆对象后，最稳妥的收尾方式是连续选入这几个库存对象，把 DC 恢复到干净状态，再交给默认处理流程。这比保存和恢复原始指针更不容易出错。

6. 进阶：用 OnDraw 一份代码打通屏幕、打印预览与打印机

走到这一步，你对消息机制、消息映射、GUI 对象都有了基本认知，可以开始体会 MFC 相对原生 API 的真正优势了。我建议你做一个练习：在单文档工程的 CView::OnDraw 里画一个简单的柱状统计图，包含坐标轴、若干矩形柱和文字标注。只需要这一份代码，屏幕显示、打印预览、打印机输出就全部正确，这就是设备无关性最直观的体现。你会发现 OnDraw 里根本不用关心当前是哪一个设备，CDC 内部已经处理了坐标映射和分辨率差异。

这里有一个打印场景的特有技巧：打印时需要为不同页调整输出区域，常见做法是在 OnPreparePrinting 里设置页数，在 OnPrint 里按页号调用不同的绘制逻辑，但无论如何最终都复用 OnDraw 里那段核心代码。我一般会在 OnDraw 开头判断传入的 DC 是否为打印机：

void CMyView::OnDraw(CDC* pDC) { BOOL bPrinting = pDC->IsPrinting(); // 判断当前 DC 是否为打印机 if (bPrinting) { // 打印时用更精细的线型和纯黑颜色，省墨且清晰 pDC->SelectStockObject(BLACK_PEN); } // 共用绘制逻辑 DrawChart(pDC); }

IsPrinting 这个判断非常实用。屏幕显示可以容忍彩色、渐变和细线，但打印机上浅色线条往往打出来一片模糊，纯黑加粗体才是可靠方案。这也是我从血泪经验里学到的——第一次把带灰色柱状图的界面直接打印，结果柱子和坐标轴几乎看不出来。

最后聊聊选书与学习节奏。这份资料里“多看书、少买书、买书前一定要慎重”的建议我一直很认同。MFC 的经典书内容大同小异，核心就是消息机制、消息映射、DC、文档视图这四块。选书时优先看目录里这四块是否讲透，代码示例是否精简。入门阶段买一本翻译过来的、章节循序渐进的书就够用了，剩下的是反复查联机帮助和读别人工程里的代码。从那以后我每次遇到消息处理不生效，都会强制走一遍“查映射表→查消息 ID→查窗口句柄归属”这个检查顺序，再没被这类问题卡过夜。希望这份拆解能帮你把 MFC 入门的这条弯路走直。

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