企业官网建设流程全解析

接手一个跑了十几年的老工业上位机项目，界面全是 MFC 写的，改一个按钮的位置都要在几百行的 .cpp 里翻半天——这大概是我最近两周最真实的处境。也正因为这个活儿，我把 MFC 窗口基础这套东西从头到尾重新捋了一遍。网上关于 MFC 教程的内容其实不少，但大部分停留在“拖控件、双击生成响应函数”这个层面，真到了要手写框架窗口、自己控制消息流向、处理客户区自适应布局、排查窗口创建失败的时候，能讲透的资料反而不多。这篇就把我这次重新梳理的 MFC 窗口基础整理出来，从窗口体系的设计思路，到 CWnd 与 HWND 的绑定关系，再到手写一个能跑起来、能塞控件、能随窗口拉伸的完整例子，最后附上踩坑记录和排查思路。适合刚接触 MFC 编程入门的朋友，也适合像我这样写了几年 C++ 但一直在业务层打转、没系统补过窗口机制的人。

1. MFC 窗口体系的整体设计与思路拆解

1.1 从 Win32 API 到 MFC：多封一层到底图什么

要理解 MFC 窗口基础，得先回到它出现之前的年代。纯 Win32 写一个窗口，你得自己定义 WNDPROC 回调函数，里面写一个巨大的 switch-case 来处理 WM_PAINT、WM_SIZE、WM_COMMAND 这些消息；窗口过程是全局函数，所以你想把状态存进去，只能靠 SetWindowLongPtr 挂一个 this 指针，然后在每个消息分支里再取出来。一个窗口如此，十个窗口就是十份重复代码，维护起来非常折磨。

MFC 做的事情，本质上是把这套流程“对象化”了。CWnd 及其派生类把 HWND 包在里面，窗口过程变成一个静态成员函数，通过句柄映射表找到对应的 C++ 对象，再把消息分发给成员函数。消息映射表（MESSAGE_MAP）是一组宏展开的静态数组，用空间换时间，避免了虚函数表在消息数量爆炸时带来的开销。这个设计在 1992 年是相当超前的，也是为什么今天回头看它依然不觉得过时——它解决的是“C++ 对象模型怎么和 C 风格的回调机制对接”这个通用问题。

所以你在写 MFC 的时候，脑子里要有一根弦：你写的每一个 afx_msg 函数，本质上都对应 Win32 世界里的一条消息，MFC 只是帮你把“消息编号 → 处理函数”这个查找过程自动化了。理解这一点，后面所有关于消息映射的困惑都会迎刃而解。

1.2 三种窗口形态：框架窗口、对话框、子控件的分工

MFC 里的窗口，粗分下来是三类。第一类是框架窗口（CFrameWnd 及派生类），它承担的是“应用程序主界面容器”的角色，带标题栏、边框、菜单，可以是 SDI 的单文档框架，也可以是 MDI 的子框架。第二类是对话框（CDialog、CDialogEx、CPropertyPage），特点是通常没有独立的菜单栏，靠资源模板或者动态创建，生命周期往往比较短。第三类是子控件，比如 CEdit、CComboBox、CTreeCtrl、CListCtrl，它们本身也是 CWnd 的派生类，只是样式上带 WS_CHILD，必须挂在一个父窗口里才能显示。

这三类的差别不只是外观。框架窗口走的是“创建 → 消息循环 → 销毁”这条完整链路，它需要你自己管理 OnCreate、OnClose、OnDestroy 这些消息；对话框有一套自己的模态消息泵（DoModal 里的 RunModalLoop），会临时接管消息分发；子控件则基本不处理生命周期，你负责创建和销毁，它负责响应交互。

实际项目里最常见的误用，是拿对话框当主窗口使——做个小工具确实没问题，但一旦要在主界面上做布局自适应、多视图切换、工具栏停靠，对话框那套机制就会处处掣肘。我这次改的老项目就是这个问题，主窗口是 CDialog 派生出来的，现在要加可停靠面板，动一行代码牵连一片，非常难受。

1.3 消息映射：MFC 窗口基础中最容易被忽略的地基

消息映射表长这样：BEGIN_MESSAGE_MAP(CMainFrame, CFrameWnd) 开头，中间是一串 ON_WM_XXX() 或者 ON_COMMAND(ID, Handler) 宏，最后 END_MESSAGE_MAP() 收尾。这几个宏展开之后，实际上是往一个静态的 AFX_MSGMAP_ENTRY 数组里塞条目，每个条目记录消息 ID、消息码、处理函数指针和参数信息。

查找过程是沿类继承链往上走的：先在当前类的映射表里找，找不到就去基类的映射表，一直找到 CWnd 的默认实现。这就解释了一个新手常见的困惑——“我明明写了 ON_WM_SIZE，为什么没被调用？”很可能是你把映射条目写在了另一个类的 BEGIN_MESSAGE_MAP 块里，或者类声明里漏了 DECLARE_MESSAGE_MAP() 宏。

注意：DECLARE_MESSAGE_MAP() 必须写在类声明的 protected 或 private 区，且必须在最后一个访问修饰符之后、类结束大括号之前。写在 public 区虽然多数情况下也能编译，但破坏了封装，某些编译器版本会给出警告。

还有一个坑是消息映射宏的匹配条件。ON_COMMAND 只处理菜单和工具栏的命令消息，按钮点击如果用的是 BN_CLICKED，得看按钮是不是走 WM_COMMAND 这条路——对话框上的按钮走 ON_BN_CLICKED，而 ON_COMMAND 是给命令 ID 用的，两者不能混。这个细节在 MFC 编程入门阶段几乎没人讲清楚，等到界面点下去没反应才回头查文档，白白浪费半天。

2. 窗口创建的关键细节与参数选择

2.1 HWND 与 CWnd 的双向绑定：句柄映射表在干什么

MFC 维护着一张全局的句柄映射表（handle map），本质上是 HWND 到 CWnd* 的哈希映射，配合临时对象的引用计数。当你调用 CWnd::FromHandle(hwnd) 时，如果这张表里已经有对应的 CWnd 对象，就直接返回；没有的话，MFC 会创建一个“临时 CWnd 对象”挂上去，等消息处理完再销毁。

这个机制解释了两个行为。第一，为什么 CWnd* 指针有时候“看起来能用但一下就跑飞了”——因为它可能是临时对象，生命周期只到当前消息处理结束。第二，为什么 GetDlgItem(IDC_XXX) 返回的指针不能长期保存，标准做法是用 DDX（数据交换）把控件变量和成员变量绑起来，让 MFC 在 DoDataExchange 里帮你维护。

如果你确实需要长期持有，正确做法是给控件单独声明一个成员变量，比如CEdit m_editInput;，然后调用m_editInput.SubclassDlgItem(IDC_EDIT_INPUT, this)或者直接用 Create 创建。SubclassDlgItem 的语义是“接管一个已经存在的 HWND”，把它的消息转发到这个 C++ 对象上，这个操作在自绘控件、控件子类化的时候特别常用。

2.2 CreateEx 参数逐个拆解与常用取值

CWnd::CreateEx 是窗口创建的底层入口，签名大致是这样：

BOOL CreateEx(DWORD dwExStyle, LPCTSTR lpszClassName, LPCTSTR lpszWindowName, DWORD dwStyle, int x, int y, int nWidth, int nHeight, HWND hWndParent, HMENU nIDorHMenu, LPVOID lpParam);

dwExStyle 是扩展样式，最常用的几个值值得记住：WS_EX_CLIENTEDGE 给客户区加一圈下沉边框，视觉上像输入框；WS_EX_TOPMOST 让窗口始终置顶，做浮动提示窗很有用；WS_EX_TOOLWINDOW 让窗口不出现在任务栏和 Alt+Tab 列表里，做托盘附近的小面板时必用；WS_EX_CONTROLPARENT 让 Tab 键能在子控件之间正确切换，容器类窗口需要它。

lpszClassName 这个参数有一个容易忽略的点：如果传 NULL，MFC 会自动注册一个默认窗口类；如果你传了一个自定义类名，就必须提前调用 AfxRegisterClass 或者 AfxRegisterWndClass 注册，否则 CreateEx 会直接失败，而且 GetLastError 返回的可能是 0，让人一头雾水。

nWidth / nHeight 是客户区尺寸，不含边框和标题栏——这一点和 Win32 的 CreateWindowEx 语义一致，但和很多人直觉里的“窗口整体大小”不一样。你要一个总宽 800 的窗口，得用 AdjustWindowRectEx 换算，或者干脆用 CRect 指定矩形后由 MFC 的 PreCreateWindow 帮你调整（CFrameWnd 默认会做这件事，但 CWnd 不会）。

2.3 窗口类注册：AfxRegisterWndClass 与手写 WNDCLASSEX 的取舍

窗口类（window class）不是 C++ 的 class，它是 Win32 层面的一个数据结构，记录了这个类型窗口的默认窗口过程、背景刷、光标、图标和风格位。MFC 提供了 AfxRegisterWndClass 这个便捷函数，一行代码就能注册：

LPCTSTR pszClass = AfxRegisterWndClass( CS_HREDRAW | CS_VREDRAW, // 风格 ::LoadCursor(NULL, IDC_ARROW), // 光标 (HBRUSH)::GetStockObject(WHITE_BRUSH), // 背景刷 NULL); // 图标

CS_HREDRAW | CS_VREDRAW 是最常用的组合，意思是窗口宽度或高度变化时整个客户区重绘。不加这两个位的话，窗口拉伸会出现残影——因为只有新暴露的区域收到 WM_PAINT，旧内容留在那里没被擦掉。这个坑我在第一次写自绘列表的时候踩得很结实，拉伸窗口后一堆旧文字叠在一起。

背景刷的选择也有讲究。用 WHITE_BRUSH 会导致每次 WM_ERASEBKGND 都刷白，如果你的 OnPaint 里是全量自绘，那这层白刷就是纯粹的性能浪费，还会带来闪烁。这时候用 GetStockObject(NULL_BRUSH) 或者干脆在 OnEraseBkgnd 里直接 return TRUE 更合适。

如果你需要更精细的控制，比如指定自定义图标、小图标、菜单名，那就得手写 WNDCLASSEX 然后调 AfxRegisterClass 注册。绝大多数业务场景用 AfxRegisterWndClass 就够了，不用过度设计。

2.4 样式位 WS_ 与扩展样式 WS_EX_ 的搭配经验

窗口样式这块，我用一张表把高频组合整理出来，方便对照：

一个反直觉的点：WS_VISIBLE 不是“创建后立刻显示”这么简单，它决定了窗口在 Create 返回时是否已经处于可见状态。如果你用 WS_CHILD 但没加 WS_VISIBLE，控件其实已经创建成功了，只是不可见，用 Spy++ 能看到它的句柄。这种情况表现出的现象就是“代码没报错，但界面上什么都没有”，新手很容易误判成创建失败。

另外，动态改样式要用 ModifyStyle / ModifyStyleEx，不要用 SetWindowLong 直接改——后者不会触发窗口重绘和框架重算，改了样式但界面没变化，也是经典坑。ModifyStyle 内部会处理 SWP_FRAMECHANGED，视图框架会跟着更新。

3. 手写一个能跑起来的 MFC 窗口：完整实操

3.1 工程准备与最小依赖配置

先说工程配置。不管你是新建还是往老工程里加，几个设置必须确认：字符集用 Unicode（项目属性 → 高级 → 字符集），不要用多字节，现在所有新代码都该走 Unicode；运行库要和依赖的第三方库一致，MD 和 MT 混用会出现一堆 LNK2005 重定义错误；预编译头 stdafx.h 或 pch.h 里至少包含 afxwin.h。

如果你的工程是纯 Win32 项目想加 MFC 支持，光改包含路径不够，得在项目属性里把“使用 MFC”设成“在共享 DLL 中使用 MFC”或“在静态库中使用 MFC”，否则链接阶段会报一堆 unresolved external。这是因为 MFC 有自己的入口点和初始化流程，光有头文件是不够的。

最小可运行的骨架只需要两个类：一个 CWinApp 派生类作为应用对象（全局唯一实例 theApp），一个 CFrameWnd 派生类作为主窗口。CWinApp 的 InitInstance 里创建并显示主窗口，返回 TRUE 就进入消息循环，返回 FALSE 就直接退出——这个返回值语义经常被忽略，导致程序一闪而过。

3.2 派生 CFrameWnd 并挂上消息映射

先写类声明。这里的关键是 DECLARE_DYNAMIC（需要运行时类型信息时用，配合 RUNTIME_CLASS 宏）和 DECLARE_MESSAGE_MAP：

class CMainFrame : public CFrameWnd { DECLARE_DYNAMIC(CMainFrame) public: CMainFrame(); virtual ~CMainFrame(); protected: CEdit m_editInput; CComboBox m_comboKind; CTreeCtrl m_treeNav; afx_msg int OnCreate(LPCREATESTRUCT lpCreateStruct); afx_msg void OnPaint(); afx_msg void OnSize(UINT nType, int cx, int cy); afx_msg void OnDestroy(); DECLARE_MESSAGE_MAP() };

实现文件里对应写 IMPLEMENT_DYNAMIC(CMainFrame, CFrameWnd) 和映射表：

BEGIN_MESSAGE_MAP(CMainFrame, CFrameWnd) ON_WM_CREATE() ON_WM_PAINT() ON_WM_SIZE() ON_WM_DESTROY() END_MESSAGE_MAP()

顺序上，BEGIN_MESSAGE_MAP 的第一个参数是当前类，第二个是直接基类，这个基类必须和 DECLARE_MESSAGE_MAP 所在的类继承关系一致。写错了不会立刻报错，但消息会查不到，表现为“父类的消息处理不生效”。

3.3 重写 PreCreateWindow：创建前改样式的唯一时机

很多人不知道 PreCreateWindow 存在的意义，觉得直接改 cs 结构体不就行了吗。问题在于，窗口一旦创建，样式位就固定了，想改只能 Destroy 再重建。PreCreateWindow 是 MFC 在真正调用 CreateEx 之前给你的最后一次“反悔机会”，参数 CREATESTRUCT& cs 是引用传递，改完直接生效。

BOOL CMainFrame::PreCreateWindow(CREATESTRUCT& cs) { if (!CFrameWnd::PreCreateWindow(cs)) return FALSE; // 去掉 MFC 自动加的“- 文档名”后缀 cs.style &= ~FWS_ADDTOTITLE; // 去掉客户区下沉边框，自绘时更干净 cs.dwExStyle &= ~WS_EX_CLIENTEDGE; // 使用自定义窗口类，带水平垂直重绘 cs.lpszClass = AfxRegisterWndClass( CS_HREDRAW | CS_VREDRAW, ::LoadCursor(NULL, IDC_ARROW), (HBRUSH)::GetStockObject(NULL_BRUSH), NULL); return TRUE; }

这里有个必须注意的点：FWS_ADDTOTITLE 是 MFC 自定义的样式位（值比较靠高位，不会和标准 WS_ 冲突）。默认情况下 CFrameWnd 会在标题后面拼接当前文档名，如果你没走文档/视图框架但标题里莫名多了个“- 无标题”，就是这个位在作怪。我第一次遇到的时候以为是 SET_TITLE 哪里写错了，翻了半天源码才发现是这个。

3.4 窗口生命周期消息的执行顺序与验证方法

窗口从生到死，消息顺序是固定的，记牢这个顺序能省掉大量调试时间：

WM_NCCREATE → WM_NCCALCSIZE → WM_CREATE → （显示后）WM_SHOWWINDOW → WM_SIZE → WM_PAINT → ……运行期…… → WM_CLOSE → WM_DESTROY → WM_NCDESTROY。

OnCreate 是初始化控件的最佳位置，此时窗口句柄已经有效，父窗口尺寸也确定了，但客户区还没最终布局完。所以如果你想在 OnCreate 里拿到准确的客户区大小，得先调 GetClientRect，得到的是创建时的尺寸，不一定等于最终显示尺寸。要拿最终尺寸，放在 OnSize 里更稳。

WM_CLOSE 和 WM_DESTROY 的区别也要分清：关闭按钮触发的是 WM_CLOSE，默认处理是调 DestroyWindow；WM_DESTROY 是窗口真的开始销毁，此时子控件已经被销毁，句柄即将失效。销毁主窗口后必须调用 PostQuitMessage(0)，否则消息循环不会退出，进程会留在后台——任务管理器里看到进程还在但窗口没了，十有八九是漏了这一句。

验证顺序最方便的办法是在每个处理函数里加 TRACE：

int CMainFrame::OnCreate(LPCREATESTRUCT lpCreateStruct) { TRACE(_T("[trace] WM_CREATE enter, cx=%d cy=%d\n"), lpCreateStruct->cx, lpCreateStruct->cy); if (CFrameWnd::OnCreate(lpCreateStruct) == -1) return -1; return 0; }

TRACE 输出到调试器的输出窗口（VS 里是“输出”面板），Release 版本自动编译掉，不留性能开销，比 MessageBox 打断流程要舒服得多。

3.5 客户区绘制与坐标换算的实操细节

OnPaint 里的标准写法是 CPaintDC dc(this)，这个对象在构造时自动 BeginPaint，析构时自动 EndPaint。如果你漏掉了 CPaintDC 而在别的地方画图，会陷入“WM_PAINT 一直触发、CPU 占用飙升”的死循环——因为系统认为你没处理完绘制请求。

坐标换算是 MFC 里另一个高频出错点，四个函数要分清：GetClientRect 返回客户区矩形，左上角永远是 (0,0)；GetWindowRect 返回屏幕坐标下的整个窗口矩形（含边框标题）；ClientToScreen 和 ScreenToClient 做局部坐标和屏幕坐标的互转。做右键菜单、弹出提示框定位的时候，必须先 ClientToScreen 把客户区坐标转成屏幕坐标，否则菜单会跑到屏幕左上角去。

void CMainFrame::OnPaint() { CPaintDC dc(this); CRect rc; GetClientRect(&rc); dc.SetBkMode(TRANSPARENT); dc.SetTextColor(RGB(60, 60, 60)); CString str; str.Format(_T("客户区尺寸: %d x %d"), rc.Width(), rc.Height()); dc.DrawText(str, &rc, DT_CENTER | DT_VCENTER | DT_SINGLELINE); // 画一条分隔线，验证重绘是否完整 dc.MoveTo(rc.left + 20, rc.CenterPoint().y); dc.LineTo(rc.right - 20, rc.CenterPoint().y); }

想验证 CS_HREDRAW | CS_VREDRAW 到底生不生效，最简单的办法就是：注册窗口类时先不加这两个位，拉伸窗口，看那条分隔线有没有残影；再加上，再拉伸，对比一下。这种“故意制造问题再修复”的验证方式，比看十遍文档都记得牢。

3.6 塞进几个常用控件：CEdit、CComboBox、CTreeCtrl

控件创建我习惯全部放在 OnCreate 里，集中管理尺寸常量，方便后面接布局逻辑：

int CMainFrame::OnCreate(LPCREATESTRUCT lpCreateStruct) { if (CFrameWnd::OnCreate(lpCreateStruct) == -1) return -1; // 单行输入框 m_editInput.Create(WS_CHILD | WS_VISIBLE | WS_BORDER | ES_AUTOHSCROLL, CRect(12, 12, 320, 40), this, IDC_EDIT_INPUT); // 下拉框：注意高度参数包含下拉展开区 m_comboKind.Create(WS_CHILD | WS_VISIBLE | CBS_DROPDOWNLIST | WS_VSCROLL, CRect(12, 48, 320, 220), this, IDC_COMBO_KIND); m_comboKind.AddString(_T("窗口")); m_comboKind.AddString(_T("控件")); m_comboKind.AddString(_T("消息")); m_comboKind.SetCurSel(0); // 树控件 DWORD dwTreeStyle = WS_CHILD | WS_VISIBLE | WS_BORDER | TVS_HASLINES | TVS_LINESATROOT | TVS_HASBUTTONS | TVS_SHOWSELALWAYS; m_treeNav.Create(dwTreeStyle, CRect(340, 12, 620, 380), this, IDC_TREE_NAV); HTREEITEM hRoot = m_treeNav.InsertItem(_T("MFC 窗口基础"), TVI_ROOT); HTREEITEM hSub1 = m_treeNav.InsertItem(_T("窗口创建"), hRoot); m_treeNav.InsertItem(_T("RegisterClass"), hSub1); m_treeNav.InsertItem(_T("CreateEx"), hSub1); HTREEITEM hSub2 = m_treeNav.InsertItem(_T("消息处理"), hRoot); m_treeNav.InsertItem(_T("消息映射表"), hSub2); m_treeNav.InsertItem(_T("自定义消息"), hSub2); m_treeNav.Expand(hRoot, TVE_EXPAND); return 0; }

这里必须重点说 CComboBox 的高度问题。Create 传的 CRect 高度，对于 CBS_DROPDOWNLIST 和 CBS_DROPDOWN 这两种风格，指的是“收起状态下编辑框高度 + 展开下拉列表的高度”。如果你按直觉只给 30 像素，下拉列表就被压成一条缝，点开什么都看不见。而这个值在创建之后就改不了了——想改只能销毁重建。我见过不少人为了这个问题去重载 OnSize 折腾半天，其实只是创建时少给了 150 像素。

CTreeCtrl 这边，节点句柄 HTREEITEM 不要跨线程保存和使用。另外 TVS_SHOWSELALWAYS 这个样式在窗口失去焦点时能让选中项保持高亮，做导航树体验会好不少，不加的话点一下别的地方选中态就没了，看起来像“选中丢了”。

4. 窗口运行中的常见故障与排查实录

4.1 创建失败：从 GetLastError 反推注册与创建环节

窗口创建返回 NULL 时，第一步永远是看 GetLastError 的返回值。但是这里有个陷阱：MFC 内部会做很多操作，GetLastError 可能被后续调用覆盖。正确的做法是在调用 Create 之后立刻取值：

if (!pFrame->Create(NULL, _T("示例窗口"), WS_OVERLAPPEDWINDOW, CRect(100, 100, 900, 640))) { DWORD dwErr = ::GetLastError(); TRACE(_T("[error] Create 失败, GetLastError=%lu\n"), dwErr); return FALSE; }

几个高频错误码的含义：1407 是“找不到窗口类”，说明 lpszClass 传了未注册的类名；1400 是“无效的窗口句柄”，通常是父窗口传错；87 是“参数错误”，多半是样式位组合不合法。如果 GetLastError 返回 0 但创建就是失败，那基本可以确定是 MFC 内部某处提前返回了 FALSE，这时候去看 CFrameWnd::Create 的返回值来源，一般和 PreCreateWindow 返回 FALSE 有关。

还有一种“假失败”值得警惕：窗口创建成功但立即被销毁。这种情况常见于 OnCreate 返回了 -1。MFC 对 OnCreate 返回值的约定是：返回 0 表示继续创建，返回 -1 表示创建失败并自动销毁窗口。新手有时候习惯性写成return 1;，这在 MFC 里也是合法的（非零非 -1 会被当成 0 处理），但如果写成 -1 就真的自毁了，表现是“Create 返回 TRUE 但窗口一闪而过”。

4.2 控件不响应、消息收不到的三类原因

控件创建成功但点了没反应，我总结下来基本逃不出三种情况。

第一种是父窗口错了。子控件的父窗口必须是它实际所在的容器。如果你的控件创建在 CFrameWnd 上，但视觉上它被放在了一个子对话框里，那点击消息会发给框架窗口而不是你以为的那个类。用 Spy++ 选中控件，看它的 Parent 是谁，一目了然。

第二种是消息映射宏用错了类型。按钮点击走 ON_BN_CLICKED（本质是 WM_COMMAND 的 BN_CLICKED 通知码），菜单和加速键走 ON_COMMAND，控件自定义通知走 ON_NOTIFY。用 ON_COMMAND 去接按钮点击，对于某些情况其实也能收到（因为都走 WM_COMMAND），但拿不到通知码，无法区分点击和其他通知。老代码里这类混用特别多。

第三种是控件被禁用或者被别的窗口盖住了。WS_DISABLED 样式会让控件灰掉且不响应，这个容易发现；被盖住则比较隐蔽——比如你创建了一个透明的 WS_EX_TRANSPARENT 窗口在上面，鼠标事件被它吃掉了。用 Spy++ 的“窗口查找”工具在目标位置点一下，能直接定位到最上层的那个窗口。

4.3 资源泄漏：GDI 对象与句柄的清理节奏

MFC 里最容易泄漏的是 GDI 对象。CFont、CBrush、CPen 这些类，构造时会创建 GDI 对象，析构时销毁。如果你把它们声明成局部变量用，离开作用域就自动清理了；但如果用 new 创建后就忘了 delete，或者把它们选进了 DC 之后就没管，泄漏会慢慢累积。

规则很简单：选入 DC 的 GDI 对象，必须在 DC 释放前选回原来的对象。标准写法是保存旧对象，用完恢复：

CPen penNew(PS_SOLID, 2, RGB(0, 120, 200)); CPen* pOldPen = dc.SelectObject(&penNew); // ... 绘制 ... dc.SelectObject(pOldPen); // 恢复，penNew 才能安全析构

如果漏了最后这一步，penNew 析构时会发现对象还在被 DC 引用，Windows 会拒绝销毁，于是这个 GDI 对象就一直挂着。进程的 GDI 对象总数是有配额限制的（默认每个进程 10000 个），到顶之后所有绘图操作都会失败，而且报错信息极其隐晦。

句柄泄漏（HWND、HANDLE）可以在任务管理器里加一列“句柄数”观察，正常应用运行时的句柄数应该是波动的、不持续增长的。持续线性增长就是泄漏信号，配合 VS 的诊断工具做快照对比能定位到具体位置。

4.4 问题速查表

把上面这些整理成一张表，出问题的时候按图索骥会快很多：

5. 窗口尺寸、布局与显示适配的实战技巧

5.1 用 WM_SIZE 做自适应布局

WM_SIZE 是布局的入口，但对它的理解有两个关键点。第一，它可能在窗口创建过程中就被触发，此时你的控件成员变量还是空的 HWND，直接调用会崩。所以 OnSize 里第一件事永远是判空：

void CMainFrame::OnSize(UINT nType, int cx, int cy) { CFrameWnd::OnSize(nType, cx, cy); // 关键：窗口最小化时 cx/cy 为 0，且创建期控件尚未就绪 if (m_treeNav.GetSafeHwnd() == NULL || cx <= 0 || cy <= 0) return; const int nMargin = 12; const int nGap = 8; const int nLeftW = 280; const int nTopH = 120; const int nBottomH = 160; // 左侧输入区：固定宽度 m_editInput.MoveWindow(nMargin, nMargin, nLeftW, 28); m_comboKind.MoveWindow(nMargin, nMargin + 36, nLeftW, 200); // 右侧导航树：宽度自适应 int nTreeX = nMargin + nLeftW + nGap; int nTreeW = cx - nTreeX - nMargin; m_treeNav.MoveWindow(nTreeX, nMargin, nTreeW, cy - nTopH - nBottomH); }

第二，GetSafeHwnd() 判空这个步骤千万别省。我见过线上崩溃的 dump 里，一大半都是 WM_SIZE 或 WM_PAINT 里访问了空句柄的控件。MoveWindow 对 NULL 句柄的容错性在不同 Windows 版本上表现不一致，早期版本直接崩溃，新版本可能静默失败，靠运气写代码迟早要还。

布局参数我建议用 const 常量集中定义，不要散落在代码里硬编码数字。这次改老项目最大的痛苦就是到处都是魔数，把 12 改成 16 得全局搜索替换，改完还得逐个数检查是不是误伤了别的 12。

5.2 关于 CDialogBar 拉伸与布局的实践

CDialogBar 是个挺实用的类，它把对话框资源模板直接变成一个可停靠的条，适合做侧边工具面板。但它有个众所周知的限制：默认情况下尺寸是固定的，想让它跟着主窗口一起被拉伸，需要额外处理。

思路是重写主框架的 OnSize，在基类处理完之后，手动调用 RecalcLayout 并调整控制条的尺寸。更稳妥的做法是通过 EnableDocking 和 DockControlBar 让它进入停靠状态，停靠状态下框架的布局引擎会接管尺寸计算。如果你想让它固定在左侧并随高度变化，可以给控制条设置 CBRS_ALIGN_LEFT 样式，再在 OnSize 里对 m_wndDialogBar 调用 SetWindowPos，高度传主窗口客户区高度。

提示：CDialogBar 内部的控件不会自动布局，因为它是基于对话框模板的固定坐标。要做自适应，得在控制条自己的类里重写 OnSize，逐个 MoveWindow。这一点和对话框的做法完全一样，不要指望有魔法。

还有一个坑是 CDialogBar 的创建时机。它必须在 OnCreate 里就创建好，晚了会导致停靠布局算错，表现出来就是控制条位置偏移或者盖在主视图上。

5.3 高 DPI 与多屏环境下的注意事项

高 DPI 环境下，如果你不做任何处理，窗口和文字会糊成一片，因为系统在做位图拉伸。解决办法是在应用启动最早的时候声明 DPI 感知级别。MFC 项目可以在 InitInstance 最开头调用：

BOOL CMyApp::InitInstance() { // 在创建任何窗口之前设置 DPI 感知 ::SetProcessDpiAwarenessContext(DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2); // ... 其余初始化 }

设成 PER_MONITOR_AWARE_V2 之后，窗口在不同 DPI 的显示器之间移动不会糊，但代价是所有尺寸都得自己按 DPI 缩放。这时候 GetDpiForWindow 就能派上用场，用它算出缩放比例，把所有硬编码的像素值乘上去：

UINT nDpi = ::GetDpiForWindow(GetSafeHwnd()); int nScale = MulDiv(100, nDpi, 96); // 相对 96 DPI 的百分比 int nMargin = MulDiv(12, nDpi, 96);

多屏环境还有个容易忽略的点：窗口位置坐标是虚拟屏幕坐标，可能有负数（主屏左边还有显示器时）。用 GetWindowRect 拿到的 left 可能是 -1920，这时候不要把坐标直接当成无符号数处理，减法顺序错了就会出现“窗口飞到屏幕外”的怪现象。

5.4 调试利器：Spy++ 与 PDB 符号的实际用法

Spy++ 是排查窗口问题最直接的工具，没有之一。它能看到窗口树结构、每个窗口的类名和样式位、实时的消息流。用法上最有价值的是“消息”视图：选中你的窗口，只勾选 WM_SIZE、WM_PAINT、WM_COMMAND 这几个，就能清楚看到消息频率和参数。如果 WM_PAINT 一秒钟刷几千次，那肯定有地方在不断 Invalidate，顺着调用栈就能找到源头。

PDB 符号这块，调试 Release 版本崩溃时特别重要。项目属性里把“生成调试信息”设成“生成优化代码的调试信息”，链接器里也打开调试信息生成，这样 Release 崩溃时能看到函数名和行号。配合符号服务器把系统 DLL 的符号也拉下来，堆栈里就不会再出现一串地址加问号的情况。

至于网上有些热词把“MFC”和完全不相干的东西混在一起，比如流量计拆解之类的，那是因为缩写撞车，跟这篇文章讲的窗口机制没有关系。搜索资料的时候注意甄别，别被带偏。

6. 把这套东西真正用起来的一点经验

窗口基础这块，我最大的体会是：不要急着上手写业务界面。花两三个小时，从一个空工程开始手写一遍 CFrameWnd 派生类，把 OnCreate、OnSize、OnPaint、OnDestroy 四个消息都实现一遍，每个里面加 TRACE，跑起来看输出顺序，这个练习的收益比看十篇教程都大——因为消息顺序这件事，只有亲眼看过才能记住。

另外一个很实用的小习惯：把常用控件的创建封装成独立的初始化函数，比如 InitInputControls、InitNavTree，在 OnCreate 里依次调用。这么做的好处是控制代码行数，OnCreate 里超过 200 行就该拆了。我这次改的项目里，有一个类的 OnCreate 有 1100 行，光是找某个控件在哪创建的就花了二十分钟。

扩展方向的话，把窗口基础打牢之后，往下可以走自定义绘制（重写 OnEraseBkgnd 消除闪烁、用双缓冲绘制复杂界面），往上可以走文档/视图架构（CDocument 与 CView 的分工、序列化机制），横向还可以学一下 MFC 的线程模型（AfxBeginThread 与窗口线程的消息通信）。这三条路都建立在同一套窗口机制之上，基础不牢的时候学哪个都是囫囵吞枣。

最后分享一个排查窗口问题的思路：遇到任何“界面不对”的问题，先问自己三个问题——这个窗口的第 0 帧状态是什么？谁负责重绘它？重绘的触发源在哪？把这三个问题回答清楚，80% 的显示问题都能自己定位，不用到处搜索。