企业官网建设流程全解析

1. 把DECLARE_MESSAGE_MAP展开给人看：消息映射表的真实长相

大部分讲MFC消息机制的资料，讲到BEGIN_MESSAGE_MAP、END_MESSAGE_MAP就收手了，顶多说一句"这两个宏建立了消息和函数的对应关系"。这话没错，但对排查问题几乎没有帮助。真正卡人的时候，你需要知道的是：这些宏到底往内存里放了什么，编译器生成的数据长什么样，运行期又是怎么在这堆数据里找到你要的那个函数。

先看DECLARE_MESSAGE_MAP()这个宏。它出现在类声明的末尾，展开后大概是这样的结构：

protected: static const AFX_MSGMAP* PASCAL GetThisMessageMap(); virtual const AFX_MSGMAP* GetMessageMap() const;

注意两个关键点。第一，GetThisMessageMap是静态成员函数，意味着它不依赖对象实例就能被调用。第二，GetMessageMap是虚函数，这一条极其重要——它保证了当你在派生类对象上调用时，拿到的是派生类的那张表。这就是MFC消息机制能够模拟"虚函数"效果的根子，后面还会反复提到。

再看BEGIN_MESSAGE_MAP和END_MESSAGE_MAP之间的部分。以较新版本的MFC头文件为例，BEGIN_MESSAGE_MAP(theClass, baseClass)展开成：

const AFX_MSGMAP* theClass::GetMessageMap() const { return GetThisMessageMap(); } const AFX_MSGMAP* PASCAL theClass::GetThisMessageMap() { typedef theClass ThisClass; typedef baseClass TheBaseClass; static const AFX_MSGMAP_ENTRY _messageEntries[] = {

而你写在中间的那些ON_WM_PAINT()、ON_BN_CLICKED(IDC_BTN_OK, &CMyDlg::OnBnClickedOk)，全部展开成_messageEntries数组里的初始化元素。最后由END_MESSAGE_MAP()收尾：

{ 0, 0, 0, 0, AfxSig_end, (AFX_PMSG)0 } }; static const AFX_MSGMAP messageMap = { &TheBaseClass::GetThisMessageMap, &_messageEntries[0] }; return &messageMap; }

看到这里你就明白了：消息映射不是一张"运行期动态注册"的哈希表，而是编译期就生成好的静态常量数组。它在程序启动前就已经完全确定了，运行期没有任何增删改的余地。这也是为什么你不可能在运行时用代码"动态添加一个消息处理"，只能通过条件编译或者手工写表来变通——当然这些变通方式都很别扭，不推荐。

1.1 表项里的六个字段分别管什么

AFX_MSGMAP_ENTRY的定义是这样的：

struct AFX_MSGMAP_ENTRY { UINT nMessage; // Windows消息ID UINT nCode; // 控件通知码，或注册消息值 UINT nID; // 控件ID（命令消息用） UINT nLastID; // ID区间结束值（RANGE宏用） UINT nSig; // 函数签名类型标识 AFX_PMSG pfn; // 函数指针 };

六个字段里，前四个是"匹配条件"，后两个是"命中后怎么调"。这个拆分非常关键，理解它就能解释很多看起来奇怪的现象。

nMessage匹配Windows消息ID，比如WM_PAINT、WM_SIZE。nCode在WM_COMMAND和WM_NOTIFY这一族消息里存放通知码，比如BN_CLICKED、EN_CHANGE，其他消息里通常是0。nID放控件ID，nLastID一般等于nID，只有用ON_COMMAND_RANGE这类区间宏时才不一样。nSig是一个枚举值，告诉MFC"这个函数指针应该按什么签名去调用"，比如AfxSig_vW表示void (UINT)，AfxSig_bWww表示BOOL (UINT, WPARAM, LPARAM)。

nSig这块是最容易被忽视、也最容易出事的。因为MFC内部保存的是AFX_PMSG这个通用成员函数指针类型，调用时通过一个union做强制转换：

union MessageMapFunctions { AFX_PMSG pfn; void (AFX_MSG_CALL CCmdTarget::*pfn_vv)(void); BOOL (AFX_MSG_CALL CCmdTarget::*pfn_bWww)(UINT, WPARAM, LPARAM); LRESULT (AFX_MSG_CALL CCmdTarget::*pfn_lWww)(WPARAM, LPARAM); // ... 还有很多种 };

如果nSig记录的是"三个参数"，但你的处理函数实际只声明了两个参数，MFC会按三个参数去压栈调用，多压的那个参数在你函数里就成了栈上的垃圾。轻则拿到奇怪的数值，重则函数返回时栈指针错位直接崩溃。我见过有人手写消息映射条目时漏掉了签名匹配，debug版本还能跑，release版本一调就崩——因为release下栈帧布局不同，运气不好就挂了。

1.2 为什么它是一段段"串起来"的链，而不是一张大平表

END_MESSAGE_MAP生成的那个静态messageMap结构体，只有一个指向基类GetThisMessageMap的函数指针和一个指向本类_messageEntries的指针。这意味着每个类只知道"我的条目"和"怎么找到我爹的条目"。

查找的时候，代码是这样走的：

const AFX_MSGMAP* pMessageMap = GetMessageMap(); for (; pMessageMap != NULL; pMessageMap = pMessageMap->pfnGetBaseMap()) { const AFX_MSGMAP_ENTRY* lpEntry = AfxFindMessageEntry(pMessageMap->lpEntries, message, code, id); if (lpEntry != NULL) { // 命中，按nSig调用pfn return TRUE; } }

外层循环沿着继承链一级一级往上爬，内层AfxFindMessageEntry在每一级自己的数组里做顺序线性扫描，一直扫到AfxSig_end哨兵为止。

这个设计有两个直接后果，都是实践中的硬约束。

第一个后果：派生类的映射优先命中。你在派生类里写了一个和基类同ID的ON_BN_CLICKED，基类那个就永远不会被调到了。这经常被当成"覆盖"来用，但也经常是bug来源——某人在继承链中间加了一层，重写了某个命令处理，结果最底层的定制逻辑就悄无声息地失效了。我在一个维护多年的老项目里遇到过这种事，一个下拉框的选中逻辑怎么都不对，查了两天才发现是中间某层基类悄悄加了一条ON_CBN_SELCHANGE，把子类那条挡住了。

第二个后果：每个类的条目是线性扫描的。一个窗口类的消息映射通常也就几十条，扫描成本可以忽略。但如果你在一个类里塞了几百条ON_COMMAND_RANGE割出来的碎片条目，命中靠后的消息时就会多扫很多次。这种情况我建议改用区间宏合并，而不是一条一条列。

1.3 静态表的隐含好处：不受对象生命周期影响

因为_messageEntries和messageMap都是函数内的static对象，它们的存在和任何窗口实例没关系。你销毁了所有窗口，这些表还在；你创建第一个窗口之前，表也已经存在了。

这个特性带来一个很实用的推论：你可以在窗口还没创建的时候，代码里就手工遍历这张表。比如做一些静态检查工具，或者做框架层的"这个类支持哪些命令"的自省。当然实际做这件事的人不多，但知道这一点，能让你在理解"为什么ON_MESSAGE的处理函数必须声明成成员函数"这类问题时更通透——因为表里存的是成员函数指针，调用时需要this，而this是AfxCallWndProc通过窗口句柄反查出来的。

顺带说一个细节：static局部变量的初始化在C++11之后是线程安全的，但在老版本MFC配合老编译器时，首次调用GetThisMessageMap是有过一次性的初始化判断的。这个判断理论上会在多线程首次并发访问时产生竞争，实际上很少有程序碰到，因为窗口类通常在UI线程里第一次被用到。知道有这回事就行，不必为此失眠。

2. 一条消息从AfxWndProc走到你的函数：中间经历了四次判断

很多人对MFC消息机制的理解停留在"系统发消息，MFC找到你的函数调用"这个层面。这个描述太粗了，粗到出了问题根本无从下手。我们把这条路径拆开，一段一段看。

2.1 窗口过程是怎么被"换"成AfxWndProc的

先要明确一个前置条件：Windows系统在派发消息时，只会调用一个函数——窗口过程（WNDPROC）。这是操作系统层面的约定，跟MFC没有任何关系。所以MFC要接管消息，第一步必须让系统在调用窗口过程时，调到的不是DefWindowProc，而是自己的AfxWndProc。

这一步是在CWnd::CreateEx内部完成的，依赖AfxHookWindowCreate。它会在窗口真正创建之前挂一个临时的钩子，在收到WM_CREATE之类的最早消息时，抢先把窗口过程替换掉，并把原来的过程保存到CWnd对象的m_pfnSuper成员里。

这里有两点值得注意。

第一，m_pfnSuper的存在意味着你没处理的消息最终还是会流回原来的过程。如果你继承的是自定义控件类，原过程可能就是某个系统控件的过程；如果你是从CWnd直接派生并自己注册窗口类，原过程就是DefWindowProc。这个设计很聪明，它让MFC可以在不完全重写窗口行为的前提下插入自己的一层。

第二，替换发生在窗口创建过程中间，所以窗口过程的第一次调用可能就是你的OnCreate，此时m_hWnd已经有效但对象未必完全初始化完毕。这也是为什么在OnCreate里访问某些成员变量可能拿到未初始化的值——初始化顺序在心智模型里得摆清楚。

2.2 AfxCallWndProc做的第一件事：把HWND翻译成CWnd*

AfxWndProc收到消息后，几乎立刻转手给AfxCallWndProc。后者做的核心事情是：通过窗口句柄，找到对应的CWnd对象指针。

CWnd* pWnd = CWnd::FromHandlePermanent(hWnd);

FromHandlePermanent和常见的FromHandle不一样。FromHandle在没有永久对象时会临时创建一个，用完在空闲时销毁；FromHandlePermanent只查永久映射表，查不到就返回NULL。MFC在这里用永久版本，是因为窗口过程收到的消息必须由一个长期存在的对象处理，临时对象撑不住。

这个细节的实践意义在于：如果你通过某种方式绕过了CWnd框架创建了一个窗口（比如直接CreateWindowEx），再指望MFC消息映射生效，是行不通的——因为永久映射表里没有对应的对象，AfxCallWndProc拿不到pWnd，直接退化成调用DefWindowProc。我见过有人动态创建控件时图省事用了裸API，然后纳闷为什么ON_BN_CLICKED不响应。原因就在这里。

拿到pWnd之后，AfxCallWndProc会依次做几件事：同步窗口状态的内部记录、检查是否是反射消息、调用pWnd->WindowProc(nMsg, wParam, lParam)。其中WindowProc是个虚函数，你可以在自己的窗口类里重写它，但绝大多数场景不该这么做——重写它等于放弃了消息映射的全部便利，退回到手写switch-case的年代。

2.3 OnWndMsg里的四次判断，顺序决定成败

CWnd::WindowProc的默认实现非常短：

LRESULT CWnd::WindowProc(UINT message, WPARAM wParam, LPARAM lParam) { LRESULT lResult = 0; if (OnWndMsg(message, wParam, lParam, &lResult)) return lResult; return DefWindowProc(message, wParam, lParam); }

所有精髓都在OnWndMsg里。它大致按这个顺序处理：

注意第1、2条里"先反射再查表"这个顺序。CWnd::OnCommand的第一件事是尝试把消息反射回发出通知的控件，只有当控件自己不吃这条消息时，才回头查父窗口自己的映射表。这个顺序反直觉，但它决定了"父窗口和子控件谁先拿到通知"这个关键问题，第3章会专门展开。

第4条里还有一个容易被忽略的分支：有几类消息即使没在映射表里找到处理函数，OnWndMsg也会做一些内部处理或者提前返回，不一定会走到DefWindowProc。比如某些涉及窗口状态同步的消息，MFC内部有自己的簿记。这属于实现细节，写业务代码时不用深究，但排查"为什么这个消息没到DefWindowProc"时有参考价值。

2.4 返回值语义：TRUE、FALSE、0、-1完全是两码事

这是消息机制里最容易混淆的一块，我把它单独拎出来说。

OnWndMsg的返回值是BOOL，语义是"这条消息我处理了吗"，返回TRUE表示已经处理、不要再交给DefWindowProc了，返回FALSE表示没处理、请继续往下传。这个BOOL和最终返回给系统的LRESULT完全是两个东西。

LRESULT是给系统的回答，比如WM_ERASEBKGND返回非0表示"背景我擦了"，WM_CTLCOLOR返回一个画刷句柄。OnWndMsg通过出参pResult把LRESULT带出去。

而消息处理函数本身的返回值语义又是另一层：ON_WM_PAINT对应的函数是void OnPaint()，没有返回值；ON_MESSAGE对应的函数是LRESULT OnXxx(WPARAM, LPARAM)，必须显式返回一个值。

我踩过的坑是这样：写了个ON_MESSAGE(WM_MY_MSG, &CMyWnd::OnMyMsg)，函数体里干完活忘了写return 0;。debug下碰巧返回值寄存器里是0，一切正常；release下某些优化路径下返回了非0，导致上游某个SendMessage的调用方判断失误，走错了分支。这种问题极难定位，因为现象和代码看起来毫无关联。从那以后我养成了一个习惯：所有ON_MESSAGE处理函数，第一行先写LRESULT lResult = 0;，最后统一return lResult;，绝不省略。

还有一类更隐蔽的问题：ON_COMMAND和ON_UPDATE_COMMAND_UI的配合。如果你的ON_COMMAND处理函数没写，但写了ON_UPDATE_COMMAND_UI，菜单项会显示为可用、也可能显示为禁用，取决于pCmdUI->Enable()的调用结果，但点击后毫无反应。这种情况不报错、不崩溃，就是"点了没用"，新手很容易在这里耗掉半天。

3. 反射消息：控件为什么要把消息"退回"给父窗口

控制台里打印一下消息流你会发现，按钮被点击时，WM_COMMAND是先发给按钮本身、再由按钮发给父窗口的（准确说是按钮在处理WM_LBUTTONUP时SendMessage给父窗口）。这是Windows的原生行为，跟MFC无关。

问题就来了：如果我想写一个自定义按钮类，让"被点击"的逻辑写在按钮类内部，而不是散落在父对话框的代码里，原生机制是不支持的——因为通知天然发往父窗口。MFC的反射机制就是为解决这个问题而生的。

3.1 反射是怎么实现的：一个固定偏移的消息ID

反射的机制朴素得有点可爱：父窗口收到WM_COMMAND后，先不查自己的表，而是把这条消息原封不动地发回给子控件，只是把消息ID加上一个固定偏移。

#define WM_REFLECT_BASE 0xBC00 // 反射消息 = WM_REFLECT_BASE + 原消息ID // 例如 WM_COMMAND (0x0111) 的反射版是 0xBD11

CWnd::OnCommand里的逻辑大致是：如果lParam里带着有效的控件句柄、且通知码为0，就调ReflectLastMsg(hWndCtrl)，把当前消息打包后SendMessage回子控件。子控件的窗口过程收到这个0xBD11的消息，OnWndMsg识别出这是反射消息，剥掉偏移还原成WM_COMMAND，再去子控件的映射表里找ON_CONTROL_REFLECT这类条目。

对应的宏家族是这样的：

用ON_CONTROL_REFLECT的时候，条目里的nID是0，nCode是通知码。也就是说它不关心是哪个ID发来的，只要是这个类的实例收到这个通知码就响应。这个设计合理，因为类内部本来就不该知道自己的控件ID是多少。

3.2 反射优先于父窗口自己的映射

回到那个顺序问题。OnCommand先反射、反射不成功才查自己的表。这意味着：

如果子控件用反射处理了某个通知，父窗口对应的映射就永远不会被调用。

这个特性既是功能也是陷阱。功能在于它让你可以把逻辑封装进控件类；陷阱在于当你继承了一个第三方或历史遗留的自定义控件类，而它内部悄悄反射了某个通知，你在父窗口写的处理函数就静默失效了。没有任何警告，没有编译错误，就是"不生效"。

排查这类问题的方法：在父窗口处理函数的第一行下断点，如果根本没停下来，就说明消息在更早的环节被吃掉了。然后去子控件的类声明里搜一下_REFLECT，八成能找到元凶。

3.3 反射失效的三种典型原因

反射机制看着简单，实际用起来坑不少，我总结出三类高频问题。

第一类：控件不是CWnd的派生对象。反射的前提是子窗口句柄能通过FromHandlePermanent找到对应的CWnd*。如果你把一个纯资源对话框模板里的静态文本当控件用，它背后确实有个CWnd对象，反射没问题。但如果是运行时裸API创建的窗口，就找不到对象，反射自然失败，消息直接落到父窗口。

第二类：ON_NOTIFY_REFLECT和ON_NOTIFY_REFLECT_EX混用搞错返回值。_EX版本的函数返回BOOL，返回TRUE表示"我处理了，父窗口别管了"，返回FALSE表示"我处理了，但也让父窗口知道一下"。这两个宏的签名不同，nSig也不同，写错了编译期不报错，运行期直接崩。这事我在做一个自定义列表控件时干过，函数原型照着_EX写的，宏写成了非_EX版本，编译通过，一跑就挂。

第三类：反射消息被中间层拦截。如果你的控件嵌在另一层容器里（比如自定义控件放在自定义面板里，面板再放在对话框上），反射只回传给直接父窗口，也就是那个面板。面板如果没把消息继续往上递，对话框就收不到。这种情况下通常要在面板里也加一条转发逻辑，或者干脆不用反射，直接让面板处理。

4. 自定义消息与ID区间：消息映射表的扩展写法

只要做稍微复杂一点的模块间通信，就一定会碰到自定义消息。这块看着简单，实际选型上分歧很大，我见过同一个项目里三四个人用三种不同的方式定义自定义消息，最后互相干扰。

4.1 WM_USER、WM_APP和RegisterWindowMessage的边界

三者的关系可以用一张表说清楚：

WM_USER的问题在于它只在一个窗口类内部有定义权。你写了个控件用WM_USER + 100，然后又写了个对话框也用WM_USER + 100，两者要是碰巧有消息转发，就会串。更麻烦的是系统控件和第三方控件也可能占用了这些值。

WM_APP稍好，它是"整个应用"级别的。但同一个进程里模块多了，谁占哪个值还是要靠人肉约定。我的做法是在项目里搞一个集中的头文件，所有自定义消息在这里统一登记，写上编号、用途、参数含义，严禁散落在各个cpp里。这个习惯救过我好几次，尤其是接手别人代码的时候。

RegisterWindowMessage返回的是系统全局唯一的值，同一个字符串在任何进程里注册都拿到同一个数。它的典型用途是跨进程通信——比如两个独立进程的窗口之间靠PostMessage打招呼。用这个的时候要注意：返回值必须存进一个静态变量或者全局变量，而且要在消息映射表被使用之前完成注册。ON_REGISTERED_MESSAGE宏的第一个参数是个const UINT&引用，MFC在运行期求值，所以注册时机只要早于第一条消息到达就行，一般放在InitInstance里足够。

注意事项：RegisterWindowMessage注册的字符串要有足够区分度。用"MY_MSG"这种名字，撞车的概率不低。建议带上模块前缀和一个版本号，比如"ACME_REPORT_PANEL_READY_V2"。

4.2 ON_MESSAGE的签名陷阱和参数打包

ON_MESSAGE对应的函数签名固定是：

afx_msg LRESULT OnMyMessage(WPARAM wParam, LPARAM lParam);

两个参数都是整型宽度，LPARAM在64位下是8字节。这意味着你要传一个结构体或者对象指针过去，只能靠转换。

// 发送端 MyData* pData = new MyData(); pWnd->PostMessage(WM_MY_DATA, 0, (LPARAM)pData); // 接收端 LRESULT CMyWnd::OnMyData(WPARAM wParam, LPARAM lParam) { MyData* pData = reinterpret_cast<MyData*>(lParam); if (pData != nullptr) { // 处理 delete pData; // 谁分配谁释放，这里约定由接收方释放 pData = nullptr; } return 0; }

这段代码能跑，但隐患不少。第一，如果接收窗口在你发送后就销毁了，PostMessage投递的消息会滞留在队列里，然后窗口销毁时被丢弃，pData就泄漏了。第二，如果发送方和接收方对"谁负责释放"约定不一致，就是双重释放或者泄漏。第三，指针跨线程传递时，如果对象生命周期不受控，就是悬空指针。

我的建议是：能用值传递就别传指针。数据量小的时候，把几个字段打包进WPARAM和LPARAM，或者塞进一个小的std::shared_ptr（这个要注意跨线程引用计数是原子的，安全），比裸指针省心得多。真要传复杂数据，用WM_COPYDATA或者干脆走一个受控的队列，别在消息参数里做文章。

还有一个非常隐蔽的坑：ON_MESSAGE处理函数的返回值必须是LRESULT，不能是void，也不能是BOOL。写错了在某些编译配置下会报错，但如果你同时用了ON_MESSAGE_REFLECT之类的变体，错误信息会指向别的地方，查起来很费劲。我现在的做法是把所有自定义消息处理函数的声明头部做成一个代码片段，需要的时候直接插入，避免手打出错。

4.3 ID区间宏：批量控件的高效写法

对话框上摆三十个复选框，每个都要写一条ON_BN_CLICKED加一个处理函数，代码会膨胀到没法看。这时候该用ON_CONTROL_RANGE：

// 头文件 afx_msg void OnCheckRange(UINT nID); // 消息映射 BEGIN_MESSAGE_MAP(CMyDlg, CDialogEx) ON_CONTROL_RANGE(BN_CLICKED, IDC_CHK_01, IDC_CHK_20, &CMyDlg::OnCheckRange) END_MESSAGE_MAP() // 实现 void CMyDlg::OnCheckRange(UINT nID) { CButton* pBtn = (CButton*)GetDlgItem(nID); if (pBtn != nullptr) { bool bChecked = (pBtn->GetCheck() == BST_CHECKED); // 根据nID分派到具体业务 } }

函数签名多了一个UINT nID参数，MFC会把实际命中的控件ID传进来。对应的nSig是AfxSig_vW，跟普通的ON_BN_CLICKED（AfxSig_vv）不同，这个差异内部处理掉了，你只要保证函数签名写对就行。

这个宏生效的前提是ID值必须连续。资源编辑器里新建控件时ID是自增的，但不保证连续，中间删过控件就会断档。所以用之前务必打开resource.h核对一下范围。我见过有人想当然地写了IDC_CHK_01到IDC_CHK_20的区间，实际中间断了好几个号，结果部分复选框点了没反应，查了半天以为是消息映射的问题。

同样的思路还有ON_COMMAND_RANGE（用于菜单和工具栏按钮）和ON_UPDATE_COMMAND_UI_RANGE。后者的函数签名是void OnUpdateRange(CCmdUI* pCmdUI)，需要在函数内部用pCmdUI->m_nID判断具体是哪个。我在做批量权限控制的时候用过这个，把一组菜单项的启用状态在一个函数里统一处理，代码量直接砍掉三分之二。

5. PreTranslateMessage和OnIdle：消息循环里两条容易被滥用的旁路

消息映射管的是"消息已经派发到窗口之后"，但消息从队列出来到派发之间，还有一段路。这段路上有两个钩子：PreTranslateMessage和OnIdle。用好了能解决一些难缠的交互问题，用不好就是性能黑洞。

5.1 PreTranslateMessage的调用时机和它该干的事

CWinThread::PumpMessage的流程是：

BOOL CWinThread::PumpMessage() { // ... if (!PreTranslateMessage(&m_msgCur)) { ::TranslateMessage(&m_msgCur); ::DispatchMessage(&m_msgCur); } return TRUE; }

PreTranslateMessage返回TRUE，消息就被吃掉，不再往下走；返回FALSE，才进入标准的TranslateMessage加DispatchMessage。

这个方法最初存在的意义是处理键盘消息的"翻译"——比如Tab键切换焦点、方向键在控件间移动，这些逻辑需要在消息派发到具体窗口之前统一处理。MFC的默认实现里会调PreTranslateInput，而后者会对对话框类调用IsDialogMessage。

这个细节解释了一个非常经典的困惑：为什么我给对话框加了个PreTranslateMessage重写，Tab键就失灵了？因为你在重写里直接返回了TRUE或者忘记调用基类实现，IsDialogMessage没被执行，键盘导航的整套逻辑就断了。正确的写法永远是：

BOOL CMyDlg::PreTranslateMessage(MSG* pMsg) { if (pMsg->message == WM_KEYDOWN && pMsg->wParam == VK_ESCAPE) { // 拦截ESC，阻止关闭对话框 return TRUE; } return CDialogEx::PreTranslateMessage(pMsg); // 这一行绝不能丢 }

PreTranslateMessage适合处理的事：全局快捷键拦截、输入框的输入过滤、焦点切换规则调整、一些需要"先于所有窗口"生效的手势识别。它不适合处理的事：本该用消息映射处理的消息、任何耗时的操作、需要访问尚未创建的窗口的逻辑。

我见过最糟糕的用法是在PreTranslateMessage里做一个数据库查询，每次按键都查一次。整个界面卡成幻灯片。这类代码往往是渐进演化的结果——起初只是加个日志，后来变成一次校验，再后来变成一次网络请求，没人回头看这个函数被调用得多频繁。

提示：如果你需要在PreTranslateMessage里判断"这条消息属于哪个窗口"，用pMsg->hwnd加CWnd::FromHandlePermanent。别用GetFocus()，因为在WM_KEYDOWN到达时焦点可能已经变了。

5.2 OnIdle：界面刷新的最后一班车

CWinThread::Run的主循环长这样，做了简化：

int CWinThread::Run() { for (;;) { while (!::PeekMessage(&m_msgCur, NULL, NULL, NULL, PM_NOREMOVE)) { if (!OnIdle(lIdleCount++)) break; // 没有消息 && OnIdle返回FALSE 时，等待下一条消息 ::WaitMessage(); } do { if (!PumpMessage()) return ExitInstance(); } while (::PeekMessage(&m_msgCur, NULL, NULL, NULL, PM_NOREMOVE)); } }

关键点在于那个while (!::PeekMessage(...))循环：只有在消息队列为空的时候，OnIdle才会被调用。而且在一个空闲周期内，它会以递增的lIdleCount被反复调用，直到返回FALSE或者来了新消息。

这个特性让OnIdle成为做"延迟初始化"和"批量刷新"的理想位置。比如你有十个面板都要在启动时加载数据，如果全放在OnInitDialog里，界面会白屏好几秒。改成在OnIdle里每次处理一个，用户就能看到界面一块一块地长出来，体感完全不同。

BOOL CMyApp::OnIdle(LONG lCount) { BOOL bMore = CWinApp::OnIdle(lCount); if (m_nPendingPanel < m_nTotalPanels) { LoadPanel(m_nPendingPanel++); bMore = TRUE; // 告诉框架还有活要干，继续调我 } return bMore; }

这里的bMore返回值语义容易搞混。返回TRUE表示"我还有事，别睡，继续调OnIdle"；返回FALSE表示"我没事了，可以进入等待消息状态"。如果你一直返回TRUE，主线程会进入忙等，CPU占用直接拉满。这个坑我踩过一次，程序跑起来风扇狂转，最后发现是某个分支忘了把bMore置回FALSE。

CWinApp::OnIdle的默认实现本身也干了不少事，其中最重要的是清理临时对象映射表（AfxLockTempMaps相关机制）。CWnd::FromHandle这类调用产生的临时对象就是靠这一机制回收的。所以，如果你重写了OnIdle并且没有调用基类实现，临时对象会越积越多，最终内存暴涨。这个后果不是立刻显现的，可能要跑好几个小时才暴露，排查难度极高。

6. 一次"点击没反应"的完整排查链路

前面讲的都是原理，这一章讲一次真实的排查过程。现象很普通：某个对话框上的"保存"按钮，点击后什么也没发生，不报错、不崩溃、鼠标有按下效果，日志里没有任何输出。

第一步，先确认消息有没有到达窗口。我在对话框的消息映射里临时加了一条ON_COMMAND(IDC_BTN_SAVE, &CMyDlg::OnDebugSave)，函数体只打日志。跑起来点按钮，日志出来了。这说明消息到了对话框，问题出在映射的处理函数里。

第二步，检查是不是被别的条目抢先命中。MFC是沿继承链从派生类往上找的，同一个类内部则是按数组顺序线性扫描，先写的先命中。我把整个对话框类以及所有基类的映射表都翻了一遍，找有没有重复的IDC_BTN_SAVE。在某个中间基类里找到了一条ON_COMMAND(IDC_BTN_SAVE, ...)，但那是另一个类，不影响本类的映射。这条排除。

第三步，检查反射有没有吃掉消息。按钮是标准CButton，不是自定义类，理论上不会有反射。但我还是在父窗口处理函数的第一行下了断点，运行后断点停住了。说明消息确实进了我的函数。

第四步，看函数体到底做了什么。这时候问题已经很清楚了——函数确实被调用了，但里面有一步条件判断提前return了。条件是"当前选中的行不为空"，而实际运行场景下选中行的索引是个无效值，所以直接返回。

第五步，往上追为什么索引无效。这是个列表控件，选中行索引从GetNextItem(-1, LVNI_SELECTED)取。问题在于，用户先点了列表某行，然后点按钮，理论上应该有效。但如果在点列表时触发了一次数据重载，列表被清空又重建，索引就丢了。追下去发现重载逻辑写在了ON_NOTIFY(LVN_ITEMCHANGED, ...)里，而这条通知在"取消选中旧行"和"选中新行"时会各触发一次，第一次触发时把列表清空重建，第二次触发时已经乱套了。

最终修复是在LVN_ITEMCHANGED处理里加一个状态判断，只在uChanged包含LVIF_STATE且新状态是选中时才走重载逻辑。另外把重载做成异步的，避免在处理通知的过程中修改控件内容。

这次排查走下来，最有价值的经验是：不要跳过"确认消息是否到达"这一步直接读代码。很多人一看按钮没反应，第一反应就是翻函数实现，结果函数根本没被调用，白读半小时。先加一条调试用的映射，或者下个断点，一分钟就能把范围砍掉一半。

同类问题的其他常见原因，我也整理了一下：

7. 消息映射不该替代虚函数：几个边界判断

用了几年MFC之后，我逐渐形成一个判断标准：消息映射是给"外部世界推过来的事件"用的，虚函数是给"我自己设计的扩展点"用的。混淆这两者，代码会变得很难维护。

消息映射适合的场景：窗口消息（WM_PAINT、WM_SIZE）、命令消息（菜单、工具栏、快捷键）、控件通知（按钮点击、编辑框内容变化）、自定义的跨模块消息。这些事件的共同点是——它们来自框架或系统的驱动，不由你控制。你只能响应，不能改变调用时机。

虚函数适合的场景：控件的绘制策略（DrawItem）、子类化时机（PreSubclassWindow）、数据交换规则（DoDataExchange）、窗口创建前的定制（PreCreateWindow）。这些的共同点是——它们是框架留给你的钩子，调用时机由框架保证，语义清晰。

看到这里的区别了吗：消息映射是"被动响应未知时机的事件"，虚函数是"主动填充框架预留的位置"。前者是松耦合的回调表，后者是紧耦合的继承契约。

我在一个项目里见过反例：有人把"窗口初始化"写成了一条自定义消息，在OnInitDialog末尾PostMessage给自己，然后在处理函数里做初始化。理由是"这样能确保窗口已经完全显示"。这个做法不是不能用，但它把一条本可以顺序执行的逻辑变成了异步的，调试时断点跳来跳去，读代码的人完全看不出执行顺序。后来这个模块交接到别人手上，第一周就在问"这个WM_MY_INIT到底什么时候发出来的"。

另一个常见误用是用消息映射实现"父子窗口通信"。子窗口调GetParent()->SendMessage(WM_XXX)，父窗口处理。这在一层关系里还能接受，但一旦嵌套超过两层，消息会沿着窗口树往上冒，中间任何一层都可能拦截或者忽略，链路变得不可追踪。我现在更倾向用接口指针或者回调std::function，在构造时注入，调用路径一目了然。

当然也有反过来的情况：有些东西确实只能用消息映射。比如ON_UPDATE_COMMAND_UI，这个机制和MFC的命令路由深度绑定，没有虚函数可替代。再比如跨线程通信，PostMessage是唯一不阻塞的官方手段。所以不是"消息映射不好"，而是要清楚它在哪个层面解决问题。

最后一个我经常提醒队友的点：消息映射里的代码要短。一条映射处理函数超过三十行，基本就该抽函数了。原因很实际——消息映射的条目是分散在宏列表里的，你从宏找到函数，再从函数读逻辑，中间有一次上下文跳跃；如果函数还特别长，读代码的人就要来回翻。而抽成普通成员函数之后，名字本身就是文档，RefreshDetailPanel()比一大段内联代码好读得多。

我在这个框架上折腾的时间不算短，从最开始把它当成"会自动调函数的魔法"，到后来能闭着眼睛推断一条消息在哪一层被吃掉，转折点就是有一天把那些宏真正展开看了一遍。那次之后很多以前靠试错解决的问题，变成了可以从数据结构和调用顺序直接推出来的结论。如果你现在还在被某条消息的诡异行为困住，我建议找个空闲的下午，把BEGIN_MESSAGE_MAP的展开结果复制到编辑器里，一个一个字段对着看，比读十篇教程都管用。