Windows资源管理实战：从.rc脚本到资源加载全解析

1. 资源是什么，为什么Windows要把资源单独维护

看到这个标题，先别急着敲代码。我在这篇笔记里想聊的“资源”，不是CPU、内存这种系统资源，而是Windows程序里的一种特殊数据段。说得直白一点，就是你的可执行文件（.exe、.dll）里附带的那部分“非代码内容”——图标、位图、光标、菜单、对话框布局、字符串文本、版本信息，以及你自己塞进去的任何自定义数据。

很多刚开始写Windows程序的朋友都有个困惑：我明明可以直接在代码里定义一个数组，或者用fopen读一个外部文件，为什么非要搞“资源”这么一套东西？这个问题我当年也问过。答案其实很朴素：窗口程序几乎天生就离不开这些附属数据，系统又需要对它们做统一管理，与其让每个程序各搞各的，不如由操作系统和编译器约定一套标准的存放方式。比如注册表里显示的图标、资源管理器右键菜单上的图标、任务栏缩略图，这些都是系统从exe的资源段里直接读出来的，如果你不在资源里放图标，程序就只能显示一个空白默认图标。

资源单独维护还有个实际好处：修改文案、换图片、更新对话框布局时，通常不需要重新编译C/C++代码，只要重编资源文件、重新链接一下就行。资源段和代码段在PE文件里是分开存储的，这也让负责本地化、汉化、美化的人有了操作空间。我自己最早感受到资源的价值，是帮一个工具软件做多语言外壳——那会儿只需要把字符串表替换掉，程序主体代码一行没动，界面就变成全英文了。

这套笔记面向的读者，我的定位是：已经会用Visual Studio建一个简单的Win32窗口，能看懂“消息循环”和“窗口过程”的概念，但还没系统梳理过资源这一块的人。如果你连窗口都还不会建，建议先把基础窗口程序跑通再回来看这篇。看完之后，你能做到三件事：在自己的项目里添加资源文件；通过代码把资源加载到内存；把加载出来的数据真正用到界面上或业务逻辑里。

2. 资源的添加：.rc脚本和resource.h才是核心

2.1 IDE里添加资源的流程，以及它背后做了什么

在Visual Studio里，给一个Win32项目添加资源，正常操作是：右键解决方案资源管理器里的.rc文件，选“添加资源”，然后挑类型。想加图标就新建Icon，想加位图就导入一张.ico或.bmp，想加快捷键表就建Accelerator。如果你在“资源视图”里操作，甚至可以图形化地拖拽对话框、调整控件位置。新手阶段，直接用IDE点鼠标完全可以。

但我必须说一句有点“反教程”的话：如果只会在IDE里点点点，你对资源的理解永远是黑的。IDE帮你生成.rc文件、自动维护resource.h、编译时调用rc.exe来编译资源，这一切都自动化得太好，反而让人看不懂背后的机制。一旦出错，比如资源加载失败、ID对不上，你就完全不知道从哪里查起。所以下面的内容，我会把IDE自动生成的这些文件的真实面目拆开讲一遍。

当你新建一个资源后，项目中会多出两类东西：一是.rc脚本文件，流行叫法叫“资源脚本”；二是配套的resource.h头文件。.rc文件是纯文本，记录了这个程序需要嵌入哪些资源；resource.h里则是一堆#define的宏，给每个资源起一个符号名，对应一个整数ID。这两者的组合，就是“资源添加”这个动作的真正产物。

2.2 一份最小可用的.rc脚本长什么样

先说结论：.rc文件本质就是一套文本描述，资源编译器rc.exe读它，生成.res文件，然后链接器把.res合入exe。下面给一份极简但完整的示例，建议你自己照着写一遍，比在IDE里点一百次都有用。

c复制// resource.h
#define IDI_MYICON        101
#define IDB_MYBMP         102
#define IDS_APP_TITLE     103
#define IDC_MYDLG         104
#define IDC_BUTTON_OK     1001

c复制// resource.rc
#include <windows.h>
#include "resource.h"

IDI_MYICON       ICON     "res\\myicon.ico"
IDB_MYBMP        BITMAP   "res\\myimage.bmp"

IDS_APP_TITLE    STRINGTABLE
BEGIN
    IDS_APP_TITLE "资源加载示例程序"
END

IDC_MYDLG DIALOGEX 0, 0, 200, 120
STYLE DS_SETFONT | WS_CAPTION | WS_SYSMENU
CAPTION "对话框窗口"
FONT 9, "微软雅黑"
BEGIN
    PUSHBUTTON "确定", IDC_BUTTON_OK, 70, 80, 60, 20
END

这份脚本里包含了四种最常见的资源类型。第一行IDI_MYICON ICON "res\\myicon.ico"的意思是：把一个叫IDI_MYICON的资源ID指向磁盘上的某个.ico文件。第二行位图同理。字符串表用BEGIN/END包裹，定义了一个ID为103的字符串，值是“资源加载示例程序”。对话框资源则描述了窗口尺寸、标题和上面摆放的按钮。

注意几点细节。路径里的反斜杠要写双份，这是C语言转义规则。图标文件路径是相对.rc文件所在目录的，工程结构一换，路径也要跟着改。字符串表里的中文直接写UTF-8的话，老版本编译器可能编出乱码，建议IDE工程用Unicode字符集，或者在.rc文件顶部加#pragma code_page(65001)来指定代码页。

2.3 资源ID的编号约定，避免跟系统“打架”

resource.h里的数字ID不是随便选的。Windows自己预留了一部分ID范围，从0到255这段，还有像IDC_ARROW、IDI_APPLICATION这类系统预定义资源，它们的ID都是固定的。你要是把自己定义的ID设成很靠前的数字，有可能和系统预设冲突，导致加载时拿到一个完全不相干的东西。

我个人的习惯是：自定义资源ID从100开始，控件ID从1000开始。这样一眼就能看出来，三位数的是资源，四位数的是控件。另外约定一组前缀：图标用IDI_（ID for Icon），位图用IDB_（ID for Bitmap），字符串用IDS_，对话框用IDD_或IDC_，菜单项用IDM_。这组约定不是我发明的，是微软早期示例代码里就有的风格，但确实好用：读到IDB_你立刻知道它是位图，不会犯“拿图标ID去加载位图”这种低级错误。

资源ID还有个隐藏属性：它可以是字符串，不一定是整数。在.rc里你可以写"MY_CUSTOM_DATA" RCDATA "data.bin"，这里MY_CUSTOM_DATA就是一个字符串形式的资源名。加载时用MAKEINTRESOURCE转换整数ID，或者直接传字符串。不过字符串资源名没有整数查找快，能用整数就用整数。

3. 资源的载入：从可执行文件里把资源捞出来

3.1 资源在PE文件里不是“文件”，是“数据段”

资源载入这个环节，我觉得是整套内容里最容易想歪的地方。打开一个exe看到图标、版本信息，很多人会以为“资源就是文件里附带的原始小文件”。对了一半，但这是误导。实际上，pe文件里有一个专门叫.rsrc的节区，Windows把这些小文件按层次结构排成了一张表：第一层是资源类型（图标、位图、字符串……），第二层是资源ID，第三层是语言ID。整张表被组织成一棵三层的树。

加载资源的本质，就是在这棵树里按“类型→ID→语言”三个维度找到那份数据，然后把它映射到内存地址。这个过程由系统API帮你完成，不需要你自己去解析PE结构。这部分内容如果你以后想深入研究PE格式，会接触得更深；现阶段只需要知道，API会根据你传的类型、名称、语言参数去遍历资源树。

3.2 核心三板斧：FindResource、LoadResource、LockResource

在Win32 API里，通用的资源加载流程是三步走。第一步用FindResource找到句柄，第二步用LoadResource把资源“载入”，第三步用LockResource拿到指针。我先把代码贴出来，然后逐行说明。

cpp复制// 加载自定义RCDATA资源的通用函数
// 返回指向资源数据的指针，并把数据大小写到 pdwSize
LPVOID LoadRawResource(HMODULE hModule, LPCTSTR lpName, LPCTSTR lpType, DWORD* pdwSize)
{
    HRSRC hRes = FindResource(hModule, lpName, lpType);
    if (hRes == NULL) {
        DWORD dwErr = GetLastError();
        // 常见错误码：ERROR_RESOURCE_TYPE_NOT_FOUND(1813)
        // ERROR_RESOURCE_NAME_NOT_FOUND(1814)
        // ERROR_RESOURCE_LANG_NOT_FOUND(1815)
        return NULL;
    }

    HGLOBAL hGlobal = LoadResource(hModule, hRes);
    if (hGlobal == NULL) {
        return NULL;
    }

    LPVOID pData = LockResource(hGlobal);
    if (pData == NULL) {
        return NULL;
    }

    *pdwSize = SizeofResource(hModule, hRes);
    return pData;
}

FindResource的第一个参数hModule，传NULL就是取当前exe里的资源。如果资源在DLL里，这里要传DLL模块的句柄。第二个参数是资源ID，整数ID要先用MAKEINTRESOURCE宏转成LPCTSTR，字符串资源名就直接传字符串。第三个参数是资源类型，内置类型传RT_ICON、RT_BITMAP、RT_STRING、RT_RCDATA这些宏，自定义类型传字符串。

FindResource返回的HRSRC其实不是数据指针，而是一个定位句柄，指向资源表里的某个节点。LoadResource这个名字容易让人误会——在早期的Windows（16位时代），它确实会实际加载数据；但如今在32位/64位Windows上，资源数据在exe被加载进内存时就已经映射好了，LoadResource和LockResource并不会做真正的“从磁盘读取”动作，而只是帮你计算并返回一个有效地址。所以这个三板斧的效率非常高，不用担心像读文件那样有I/O开销。

3.3 为什么字符串、图标、位图有专门的加载函数

三板斧是通用的“底层接口”，但日常开发里，你很少直接用它处理图标和位图。系统为你封装好了几个专用函数：LoadIcon、LoadBitmap、LoadString、LoadMenu、LoadCursor、LoadDialog。这些函数内部已经做完了查找、加载、转换的工作，省去很多麻烦。

以LoadIcon为例：

cpp复制HICON hIcon = LoadIcon(hInstance, MAKEINTRESOURCE(IDI_MYICON));

这一行干完了三板斧的全部工作，而且返回的是一个已经封装好的HICON句柄，可以直接交给WM_SETICON消息或者SetClassLongPtr使用。再看LoadString，它不是返回指向字符串表数据的指针，而是一份拷贝，这是因为字符串表在内部是按“每16个字符串一组”的结构存储的，不是连续字符串，直接拿指针容易出错、也容易跨组越界，所以系统设计成在堆上拷贝一份给你：

cpp复制TCHAR szTitle[128] = { 0 };
LoadString(hInstance, IDS_APP_TITLE, szTitle, 128);

不过我得提醒一句：在WM_CREATE、窗口过程里频繁调用LoadString时，系统每次都会重新拷贝一份，如果循环次数很多，会有少量性能损耗。最稳妥的做法是在初始化阶段把需要的字符串统一读出来缓存到全局变量。下面的代码里有一个优化过的封装，你可以直接抄。

对于位图，还有一类叫LoadImage的通用函数，它可以按需加载图标、光标或位图，还支持从文件路径加载，比LoadBitmap更灵活：

cpp复制HBITMAP hBmp = (HBITMAP)LoadImage(
    hInstance,
    MAKEINTRESOURCE(IDB_MYBMP),
    IMAGE_BITMAP,
    0, 0,
    LR_DEFAULTSIZE
);
// 参数说明：第4、第5个参数是期望宽高，0表示使用资源的原始尺寸；
// 最后一个参数常用 LR_DEFAULTSIZE | LR_LOADFROMFILE，后者表示从文件加载而不是资源

3.4 自定义资源RT_RCDATA：往exe里塞任意数据

前面三板斧那段代码，其实最适合的场景就是自定义资源。Windows提供了一种叫RCDATA的资源类型（宏定义为RT_RCDATA），它就是一个无名无姓的二进制块，你想往里面放什么就放什么：配置文件、JSON、SQL语句、加密密钥、机器学习模型权重，都可以。

为什么要塞进exe而不是放外部文件？我碰到过的真实场景主要有三个：第一，程序要分发给客户，但你不希望配置文件被轻易修改（虽然不能完全阻止，但至少增加一点门槛）；第二，安装部署环境只有一个exe文件，不依赖一堆杂七杂八的外部文件，方便拷贝；第三，有些发布流程会做数字签名，外部数据文件改了签名就失效，但资源在exe里是跟着签名走的。

下面演示怎么往RCDATA里塞一个JSON文本文件，然后在程序里读出来。

c复制// resource.rc 中增加：
// IDS_CONFIG_DATA  RCDATA  "config.json"

cpp复制// 读取配置示例
void LoadAndUseConfig()
{
    DWORD dwSize = 0;
    LPVOID pData = LoadRawResource(NULL, MAKEINTRESOURCE(IDS_CONFIG_DATA), RT_RCDATA, &dwSize);
    if (pData == NULL) {
        // 处理错误
        return;
    }

    // 注意：pData 指向的内存末尾不保证有 '\0'
    // 如果要用字符串函数处理，需要自己分配缓冲区并拷贝
    std::string configText(static_cast<const char*>(pData), dwSize);

    // 在这里用 JSON 库解析 configText
}

这里有个特别容易踩坑的地方：很多人拿到pData之后直接当成字符串用，调strlen或者printf，结果要么读到资源后面的内存垃圾，要么乱码。原因就在于资源数据末尾没有自动补终止字符\0。所以要么你用二进制方式处理，要么像我上面这样，用“指针+长度”的方式拷贝成标准字符串，再走后续逻辑。

4. 资源的使用：把加载到的数据真正用起来

4.1 给窗口挂上自定义图标和位图背景

资源加载出来了不能光看着，要用到界面上。图标是最直观的用法。在窗口创建前，通过WNDCLASSEX的hIcon字段指定类图标，创建后还能通过SendMessage动态修改窗口标题栏的小图标。

cpp复制// 在注册窗口类时指定图标
WNDCLASSEXW wcx = { 0 };
wcx.cbSize = sizeof(WNDCLASSEXW);
wcx.lpfnWndProc = WndProc;
wcx.hInstance = hInstance;
wcx.hIcon = LoadIcon(hInstance, MAKEINTRESOURCE(IDI_MYICON));
wcx.hIconSm = LoadIcon(hInstance, MAKEINTRESOURCE(IDI_MYICON));
wcx.hCursor = LoadCursor(NULL, IDC_ARROW);
wcx.hbrBackground = (HBRUSH)(COLOR_WINDOW + 1);
wcx.lpszClassName = L"ResourceDemoClass";
RegisterClassExW(&wcx);

位图的使用会更复杂一点，因为你要处理绘制。最基础的做法是在WM_ERASEBKGND消息里绘制位图作为窗口背景，或者用一个静态控件的SS_BITMAP风格直接显示。还有一种常见方式是通过LoadBitmap把位图句柄拿下来，再通过CreateCompatibleDC、SelectObject、BitBlt这套GDI流程绘制到窗口DC上。

cpp复制case WM_PAINT:
{
    PAINTSTRUCT ps;
    HDC hdc = BeginPaint(hWnd, &ps);

    // 创建设备上下文，关联位图
    HBITMAP hBmp = LoadBitmap(hInstance, MAKEINTRESOURCE(IDB_MYBMP));
    HDC hdcMem = CreateCompatibleDC(hdc);
    HGDIOBJ hOldObj = SelectObject(hdcMem, hBmp);

    BITMAP bmpInfo;
    GetObject(hBmp, sizeof(bmpInfo), &bmpInfo);
    BitBlt(hdc, 0, 0, bmpInfo.bmWidth, bmpInfo.bmHeight, hdcMem, 0, 0, SRCCOPY);

    SelectObject(hdcMem, hOldObj);
    DeleteDC(hdcMem);
    DeleteObject(hBmp);

    EndPaint(hWnd, &ps);
    return 0;
}

4.2 字符串表在工程里的正确打开方式

字符串表加载出来之后，我看到很多示例代码都是直接调LoadString再用。这没什么不对，但我想分享一个更工程化的做法：定义一组统一的字符串加载接口，把常用的标题、提示信息、错误信息全部存进字符串表，代码里按ID引用。

这样做的收益是：如果后续要做多语言版本，只需要替换资源里的字符串表，不需要碰任何C代码。我自己做过一个小工具的中英双语版，就是靠这一招省了至少一晚上的复制粘贴时间。思路是写一个工具函数，内部根据全局语言标志决定加载哪个语言版本的字符串（通过FindResourceEx指定MAKELANGID），上层代码完全无感知。

字符串表的分组机制也值得知道：每16个字符串为一组，一组里有一个资源块。所以LoadString的缓冲区大小建议设为256或更大，别真按字符串长度来，因为它是按组读取再截断的。如果字符串超过缓冲区长度，LoadString返回的字节数不会包含终止符，容易被截断，需要仔细判断。

4.3 对话框资源和菜单资源的使用

对话框资源在Win32程序里是常用的界面载体。你可以在.rc里用DIALOGEX定义对话框布局，用DialogBox或CreateDialog在代码里实例化。需要注意的是，对话框模板里的控件ID对应到函数里的WM_COMMAND通知，这些ID就是在resource.h里定义的那些IDC_前缀的宏。

菜单资源同样走资源表。你可以在.rc里用MENU定义菜单结构，然后通过LoadMenu获取句柄，赋给窗口类或者逐个窗口设置。我记得第一次用菜单资源的时候，以为必须用CreateMenu一行行代码拼出来，后来发现只要在.rc里用文本定义好MENU块，加载后菜单自动成型，省了实在太多事。

有一点容易被忽略：菜单项点击事件里，WM_COMMAND的低16位就是你在.rc里定义的菜单项ID。如果想给菜单项关联打开某个对话框，代码模式通常是：

cpp复制case IDM_HELP_ABOUT:
{
    DialogBox(hInstance, MAKEINTRESOURCE(IDD_ABOUTBOX), hWnd, AboutDlgProc);
    return 0;
}

这种写法非常经典，也最能体现资源的价值：界面布局在资源里定义，逻辑处理在代码里，两者通过ID关联。

4.4 资源句柄的生命周期：谁创建谁释放

资源载入和使用这块，新手最容易出问题的地方不是“不会加载”，而是“乱释放”。需要熟记规则：从LoadResource拿到的HGLOBAL，不需要你去释放；LockResource返回的指针，也不需要你去free或VirtualFree。系统在模块卸载时会自动清理这块资源内存。

但LoadIcon、LoadBitmap、LoadImage、LoadMenu这些函数返回的GDI对象句柄，是需要手动释放的。DestroyIcon、DeleteObject、DestroyMenu。尤其是位图，创建得多又没释放，会积少成多，最后程序越来越卡，任务管理器里GDI对象数一路飙升到一万，系统直接报“内存不足”。

我自己的习惯是：在窗口销毁时统一清理，在每次WM_PAINT里创建的临时DC和位图，用完立即删除。写代码的时候顺手写上DeleteObject、DeleteDC，别想着“以后再说”，以后你绝对想不起来。

5. 常见问题与排查技巧实录

5.1 加载失败的错误码对照表

资源加载失败时，GetLastError()的返回值能快速定位问题。我整理了一个排查表，都是实操中反复遇到的：

真实调试中，1814是最常见的，多半是因为你改过resource.h里的宏值，但.rc文件里的ID没同步，两边不一致。IDE在这一点上会自动关联，但手写.rc时就非常依赖你自觉保持同步。我建议每次改ID都全局搜一下，把所有引用的地方都改了。

5.2 资源文件“存在但编译不进exe”的坑

有时候你在项目里看到了位图文件，.rc里也写了，但运行程序后发现图片加载不出来。这种情况十有八九是：文件没有通过资源编译器编译进.res文件，而只是一个“项目里的普通文件”。

检查方法：在Visual Studio里打开“资源视图”，如果列表里看不到你添加的资源，那它就是没被编译。右键.rc文件选“查看代码”，确认资源声明确实写在里面。还有一种情况是.rc文件在子目录，路径写死了“res\myimage.bmp”，但实际目录结构里没有res这个文件夹，编译器直接跳过，你连报错都不会收到。

解决方案是：把资源文件放进项目目录，路径用相对路径，且不要带..这种向上回溯的写法。最稳的是在.rc文件里引用时用res\\filename.bmp，同时确保物理目录存在且文件在里面。

5.3 修改资源后没生效：链接缓存问题

资源修改了，重新编译，运行程序却还是旧图标、旧文案，这个坑我踩过很多次。核心原因是链接器可能复用了旧的.res文件，尤其当你只改了.rc文件，而依赖的resource.h没变化时，IDE有时不会重新触发rc.exe编译。

强制解决方案：手动删除Debug/Release目录下的.res文件，然后重新生成。或者直接在VS里“生成→重新生成解决方案”，这样会强制全量编译。在CI环境里，这条同样适用，清缓存重编总是能解决90%的怪问题。另一个坑是编译器做了增量编译，但.rc文件的时间戳没更新——如果文件系统启用了某些同步工具，文件时间戳会异常，导致增量编译误判。最彻底的办法还是每次改完.rc都手动“重新生成”。

5.4 64位和32位程序资源差异

资源机制在32位和64位程序里基本一致，但有一个细节：LoadResource返回的地址在不同平台下解析方式不同。有少数旧代码会把资源指针强转成整数存起来，在64位环境下会截断指针，一运行就崩。所以写通用代码时，资源指针要始终保持LPVOID类型，不要用DWORD存储。

还有一个版本相关的问题是：FindResource在远古版本里不能用高ID（32767以上），不过在现在的SDK里这个限制已经放宽了。即便如此，我依然不建议用超过65535的ID，因为对话框控件的控件ID在某些版本里有符号位问题，超过高值后发送消息时容易变成负数ID，导致点击事件不触发。我们的ID规划从100到1000，完全够用，没必要挑战极限值。

5.5 不要把资源数据直接当“文件”操作

很多人刚接触RCDATA时，会想要拿到指针后直接fopen、fread。这是不行的。资源数据在内存里，没有文件系统路径，你不能用文件API操作它。正确做法是像前面那个LoadRawResource函数一样，把数据拷贝到自己的缓冲区里，然后按需处理。

如果你真的需要“独立文件”的效果，另一个思路是把数据先写入临时目录再操作：

cpp复制// 把资源数据写入临时文件的示例
void WriteResourceToTempFile()
{
    DWORD dwSize = 0;
    LPVOID pData = LoadRawResource(NULL, MAKEINTRESOURCE(IDS_CONFIG_DATA), RT_RCDATA, &dwSize);

    WCHAR szTempPath[MAX_PATH] = { 0 };
    GetTempPath(MAX_PATH, szTempPath);

    std::wstring fullPath = std::wstring(szTempPath) + L"config.json";
    FILE* fp = nullptr;
    _wfopen_s(&fp, fullPath.c_str(), L"wb");
    if (fp) {
        fwrite(pData, 1, dwSize, fp);
        fclose(fp);
    }
}

这个方案适合那些必须要文件路径才能工作的库，比如某些加密库或SQLite嵌入式数据库。把资源数据落地成临时文件，用完再删，算是一种务实的变通。

6. 一些工程上的经验和扩展思路

资源这套机制其实还能扩展到很多方向，我在项目里验证过的至少有这几个。

第一个是皮肤和主题的热切换。把不同风格的位置、颜色配置放进字符串表或自定义RCDATA数据里，程序启动时加载，界面绘制时动态读取。想换皮肤，只需要替换资源文件并重编译，或者更灵活一点，把资源数据解密后临时解析。这样做的好处是资源数据和代码逻辑分离，维护图形设计的人只需改资源，不需要碰代码。

第二个是插件式DLL的资源隔离。如果你的程序用DLL做插件，插件可以有自己独立的.rc资源文件。加载插件DLL之后，用LoadLibrary拿到的模块句柄去FindResource，资源就从DLL里找，不会和主程序冲突。这是模块化设计很关键的一个细节。比如一个软件主程序加三个功能DLL，每个DLL有自己的图标、位图、字符串表，用户只看任务栏也能分辨出当前激活的是哪个模块。

第三个是本地化多语言。资源本来就按语言ID分层的，你可以用FindResourceEx指定语言ID加载对应语言的字符串。在.rc里用LANGUAGE指令声明语言块，同一资源ID可以存放多个语言版本。代码侧不用改逻辑，只需在启动时根据系统语言设置一个全局语言ID，后续所有加载都走这个ID。

我个人的体会是，Windows资源系统是一个“越用越依赖”的东西。早期我写过不少自己解析配置文件、动态生成菜单的程序，写的时候感觉灵活，回头维护才发现到处都是散落的字符串和逻辑，改一个按钮名字要翻半天代码。后来老老实实把能放资源的都放资源，代码量肉眼可见地减少，界面结构也清楚了很多。尤其是对话框资源，直接在.rc里排版，比在代码里用CreateWindow一个个算坐标靠谱一万倍——那些坐标计算代码写起来费劲，改起来更痛苦，而对话框资源在VS里拖一拖就能完成布局。

最后分享一个小技巧，算是我多年来的固定习惯：每次新建一个Win32项目，第一步不会写代码，先建一个资源头文件，把该项目会用到的所有资源符号预先声明好，哪怕暂时用不上。.rc文件里也先把框架搭好：一个图标、一个字符串表、一个关于对话框。项目越往后期越会发现，这一步提前规划的价值怎么夸都不过分。资源ID一旦确定，全工程就是一个稳定的关联体系，后续加功能时，你的工作就是“补资源+补处理代码”，思路高度一致，工程量也变得可预测。