1. 从WinMain的四个参数说起1.1 头一次接触会懵但不该一直懵Windows开发者绕不过去的第一道门槛就是WinMain入口函数的四个参数hInstance、hPrevInstance、lpCmdLine、nCmdShow。学C语言那会儿写程序入口永远是main哪里见过这种阵仗于是所有人都被hInstance和hPrevInstance这种历史遗产型的参数搞得一头雾水。等到终于弄明白hPrevInstance在Win32里永远是NULL可以不用管紧接着又撞上新的困惑代码里到处都是HWND和HINSTANCE有的API要HWND有的API要HINSTANCE看着都是H打头、句柄结尾传错了也不报错程序就是不干活或者干脆崩溃。这个困惑非常真实我自己也是从那个状态摸爬滚过来的。直到后来被一次诡异的问题反复折磨——一个界面程序在A机器上跑得好好的换到B机器上就弹找不到资源折腾半天发现是HINSTANCE传错了模块的句柄——才真正下决心把这两个句柄的关系彻底搞清楚。这篇笔记就是对这两个概念的一次彻底解剖。我不会简单说HWND是窗口句柄HINSTANCE是实例句柄就完事那跟没说一样。我会拆开来讲它们各自的本质、来源、生命周期以及它们在窗口类注册、窗口创建、资源加载这些环节里是怎么配合的最后再附上实际开发中容易踩的坑和排查方法。1.2 这篇笔记准备解决什么问题很多教程在讲解这两个概念的时候用的都是教科书式语言比如HWND标识一个窗口HINSTANCE标识一个应用程序实例。这种话不能算错但对写代码的人帮助不大因为你不理解背后的机制遇到报错依然不会排查。我写这篇笔记的出发点是把下面几个问题一次性讲透为什么注册窗口类和创建窗口时都需要HINSTANCE而且两个位置的HINSTANCE必须是同源HWND到底是个什么东西它为什么是随用随取、销毁即失效的HINSTANCE是不是就是模块的基地址它和HMODULE有什么区别如果我把HWND和HINSTANCE传混了会发生什么系统会不会给我提示在DLL里头做窗口界面和在EXE里做HINSTANCE的处理有什么本质差别这几个问题是我在实际开发中真实遇到过的也是无数初学者反复踩坑的地方。把这些问题打通Win32的整个窗口机制基本上就串起来了。2. HWND窗口句柄窗口对象的用户态门牌号2.1 HWND到底是什么以及它从哪儿来先说结论HWND不是指针不是一个你可以直接去解引用读取数据的地址。它是一个不透明句柄本质上是窗口对象在系统窗口管理器内部的索引令牌。你可以把它理解成一张门牌号——你不需要知道门牌号背后的房子长什么样只需要拿着这个号码系统会帮你找到对应的那栋房子。在32位平台上HWND是4字节的整型在64位平台上它是8字节。你在VS里看头文件会看到DECLARE_HANDLE(HWND)这样的宏定义展开以后实际是个结构体指针的typedef。但我要强调虽然类型上它是指针的样子你永远不应该直接解引用它也不应该对它做算术运算。它的值只在窗口存在期间有意义窗口销毁之后这个数值可能被系统重新分配给其他窗口也可能变成无效值。HWND从哪里来常见的来源有这么几条路径CreateWindow或CreateWindowEx成功返回时得到一个新建窗口的HWNDFindWindow、FindWindowEx按窗口类名或窗口标题查找找到返回HWNDGetDlgItem获取对话框上某个控件的HWNDEnumWindows之类的枚举函数通过回调函数把每个顶层窗口的HWND交给你GetForegroundWindow、GetDesktopWindow这种获取特定窗口的HWND。让我用一个实际场景帮大家巩固理解。比如你要给一个窗口改标题你得先拿到这个窗口的HWND然后调用SetWindowText(hwnd, L新标题)。系统拿到这个HWND后在自己的窗口表里查一下找到对应的窗口对象然后修改内部的标题字符串。如果你给SetWindowText传的是一个已经销毁的HWND就像你拿着一个已经拆掉的房子的门牌号去敲门——那房子不存在了系统只会给你一个错误或者直接忽略。2.2 HWND的一生创建、存活、销毁HWND的生命周期严格跟着窗口对象走。窗口对象是系统内核的居民它的创建靠CreateWindowEx销毁靠DestroyWindow或者用户点击关闭按钮触发的消息循环退出。有意思的一点是HWND的值在窗口存续期间是不变的但这个值本身并不保证唯一。Windows会回收句柄值一个窗口销毁之后过一段时间创建一个新窗口完全可能拿到相同的句柄值。所以代码里如果长期保存了一个HWND而不去校验等到用的时候那个窗口可能早就没了而你手里的HWND现在指向的可能是另一个毫不相关的窗口。这是一个隐蔽的坑比直接使用已销毁的HWND导致崩溃还要恶心因为程序未必崩溃但它会操作错误的窗口。窗口存续期间HWND的权威性是绝对的。所有需要操作窗口的API几乎无一例外都接收HWND作为第一个参数。比如SetWindowText、GetWindowText操作标题和文本MoveWindow、SetWindowPos操作位置和大小ShowWindow、UpdateWindow操作显示状态SendMessage、PostMessage向窗口投递消息GetWindowLongPtr、SetWindowLongPtr查询或修改窗口的附加数据掌握了HWND的门牌号属性你就能理解为什么不能在全局变量里随便存HWND也能理解为什么很多优秀的代码在窗口销毁时都会主动清理自己保存的HWND。2.3 使用HWND的几条红线我在实际开发中总结了几条关于HWND的纪律违反任意一条都容易出事故。第一不要长期保存HWND并用它操作可能已经销毁的窗口。如果真需要跨流程保存应该保存窗口的唯一标识再重新FindWindow或者用消息钩子维护生命周期。最稳妥的做法是HWND随用随取用完不留。第二HWND是可以跨进程使用的。很多人以为句柄只在进程内有效这其实是个误解。你可以通过注册的窗口消息配合SendMessage把目标窗口的HWND传给别的进程系统在解析HWND的时候会自动定位到目标窗口所在进程的窗口表。这也是为什么SPY这类工具能跨进程查看窗口信息。但要注意虽然HWND能跨进程传窗口过程却是在创建窗口的那个线程的消息循环里执行的跨进程SendMessage是同步阻塞的处理不好会死锁。第三判断HWND是否有效的IsWindow函数并不是万能的。IsWindow只能告诉你这个数值在当前时刻是否对应一个存在的窗口但窗口对象可能正在销毁过程中或者数值恰好被回收分配给了新窗口。正确的姿势是把IsWindow当作辅助确认而不是万无一失的保证。3. HINSTANCE实例句柄模块在进程里的基座3.1 从Win16到Win32hInstance的意义变了要理解HINSTANCE绕不开一段历史。16位Windows时代每个应用程序实例都有独立的数据段hInstance标识的是这个实例的数据段。那时候进程没有独立的地址空间程序之间很容易互相踩踏所以要靠hInstance区分不同的实例。这也是WinMain第二参数hPrevInstance存在的历史原因——当时系统需要知道你是不是第一个实例好决定要不要加载某些共享数据。到了Win32时代每个进程有了独立的4GB地址空间32位hInstance的含义悄然变成了模块加载到进程虚拟地址空间时的基地址。也就是说在32位平台上HINSTANCE的值就是一个虚拟地址通常是模块的ImageBase。很多EXE默认的ImageBase是0x00400000DLL默认是0x10000000当然这个值可以通过链接器的/BaseAddress选项或ASLR机制改变。为什么我说在32位平台上因为HINSTANCE在定义上仍然是一个不透明的模块句柄而HMODULE才是模块句柄。但实际上Win32的HINSTANCE和HMODULE是同一个东西头文件里typedef是互通的你可以把一个HMODULE直接传给需要HINSTANCE参数的API反之亦然。在实践中这俩就是一回事。3.2 HMODULE和HINSTANCE其实是一回事很多教材喜欢把HINSTANCE和HMODULE分开讲好像它们是两种不同的东西。我在代码里实际互换使用过无数次从来没有出过问题。因为从Win32的设计上讲HINSTANCE和HMODULE就是同一枚硬币的两面GetModuleHandle返回HMODULE你可以直接把它传给需要HINSTANCE的LoadIcon、DialogBoxParam等函数DllMain收到的第二个参数是HINSTANCE类型的hModule你也可以直接把它当成HMODULE使用。这个互换合法的原因在于两者都指向模块在进程地址空间中的基地址。当你持有这个基地址系统就可以顺着这个地址解析DOS头、NT头、节区表从而找到模块的资源段、导出表、导入表等结构。模块句柄的来源同样有几种WinMain的hInstance参数这是EXE自己被加载时的基地址GetModuleHandle(NULL)返回进程主模块通常是EXE的实例句柄GetModuleHandle(L某DLL名)返回已加载模块的句柄注意如果模块没加载会返回NULLLoadLibrary或LoadLibraryEx返回的HMODULE常用于动态加载DLL并取资源DllMain入口函数的hModule参数这是DLL自己的实例句柄。有意思的是当你多次调用LoadLibrary加载同一个DLL时系统不会重复加载而是增加引用计数返回的HMODULE每次都一样。这也是为什么你会看到有些程序用LoadLibrary GetModuleHandle FreeLibrary的组合来查询某个DLL是否已被加载。3.3 哪些API在等一个HINSTANCEHINSTANCE最常出现的场景不是窗口操作而是资源操作。资源是Win32程序非常常用的东西——图标、位图、字符串表、对话框模板、菜单、版本信息、自定义二进制资源。这些资源被打包在PE文件里挂在模块的某个节区系统通过HINSTANCE来定位它们。凡是名字以Load、Find开头的资源API几乎都要求你传入一个HINSTANCE表示你想从哪个模块加载资源LoadIcon(hInst, MAKEINTRESOURCE(IDI_ICON))加载图标资源LoadCursor(hInst, MAKEINTRESOURCE(IDC_CURSOR))加载光标资源LoadBitmap(hInst, MAKEINTRESOURCE(IDB_BITMAP))加载位图资源LoadMenu(hInst, MAKEINTRESOURCE(IDR_MENU))加载菜单资源LoadString(hInst, IDS_STRING, buf, buflen)加载字符串资源FindResource(hInst, ...)按名称和类型定位资源然后还有一大类是对话框相关的DialogBoxParam(hInst, MAKEINTRESOURCE(IDD_DIALOG), hwndParent, dlgProc, param)CreateDialogParamDialogBoxIndirectParam这个用的是内存里的对话框模板不需要HINSTANCE看到规律没只要某个功能的实现依赖资源段就得提供HINSTANCE。窗口本身不依赖资源段所以创建窗口的核心API只需要HWND和窗口类的名字就够了HINSTANCE的作用是帮助系统找到窗口类、加载类资源。4. 两者关系窗口类和模块的绑定是关键4.1 窗口类注册时为什么要带hInstance这是整篇笔记的灵魂问题。为什么RegisterClassEx在注册窗口类的时候要用一个HINSTANCE来标记这个窗口类归属于哪个模块想象一下这个场景一个进程同时加载了主程序EXE和三个DLL每个模块都有可能注册自己的窗口类。如果没有归属信息大家把所有类名都放进一张全局表里那A模块注册了一个叫Foo的类B模块也想注册一个叫Foo的类不就冲突了吗即便是同一个代码里面注册重名类也会互相覆盖。Windows的解决方案是把窗口类按模块划分域。系统内部维护一张窗口类表每个条目由三样东西共同定位类的名字字符串或原子值注册类的模块的HINSTANCE类类型全局类还是局部类当系统需要根据某个类名查找窗口类时会用类名 模块句柄去匹配。这也解释了为什么同类名的窗口类可以由不同模块各自注册互不干扰。注册窗口类的代码大概长这样WNDCLASSEX wcex { 0 }; wcex.cbSize sizeof(WNDCLASSEX); wcex.style CS_HREDRAW | CS_VREDRAW; wcex.lpfnWndProc WndProc; wcex.cbClsExtra 0; wcex.cbWndExtra 0; wcex.hInstance hInstance; // 关键窗口类归属模块 wcex.hIcon LoadIcon(hInstance, MAKEINTRESOURCE(IDI_APPLICATION)); wcex.hCursor LoadCursor(NULL, IDC_ARROW); wcex.hbrBackground (HBRUSH)(COLOR_WINDOW 1); wcex.lpszClassName LMyWindowClass; wcex.lpszMenuName NULL; RegisterClassEx(wcex);你看出来没有wcex里的hInstance同时承担两个责任注册类时标记归属以及加载hIcon、hCursor这些资源时指定模块。如果你在这个结构体里填了一个别的模块的hInstance图标资源和窗口类归属就全乱了。4.2 创建窗口时最后一个参数到底有什么用CreateWindowEx函数的最后一个参数是HINSTANCE这段代码几乎每个Windows程序里都有HWND hwnd CreateWindowEx( 0, LMyWindowClass, // 窗口类名 L窗口标题, WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, NULL, // 父窗口 NULL, // 菜单 hInstance, // 模块句柄 NULL // 额外参数 );很多人以为这个hInstance是当前这个窗口实例的句柄这种理解是错的。它实际上是一个查询钥匙系统拿着这个模块句柄和窗口类名去窗口类表里查找匹配的窗口类。如果找到了再检查类的hInstance与你传入的hInstance是否一致。不一致或者找不到创建就失败。更深一层这个hInstance还会被用来加载窗口类的关联资源比如菜单。如果你的窗口类指定了lpszMenuName而CreateWindowEx的hInstance和注册类的hInstance不是同一个模块系统加载菜单时就会从错误的模块里找最后很可能因为找不到资源而创建失败。关键结论CreateWindowEx里的hInstance必须是注册窗口类时使用的那个hInstance。只要窗口类是用某个模块注册的之后每次创建这个类的窗口都应该传同一个模块句柄。为了验证这一点我自己做过一个实验用A模块的hInstance注册窗口类再用B模块的hInstance去CreateWindowEx同名的类结果是窗口创建失败GetLastError返回ERROR_CLASS_DOES_NOT_EXIST0x582。这个报错信息平时真的很常见。4.3 从窗口句柄反查模块句柄HWND和HINSTANCE之间有关系但这个关系不是直接对应而是通过窗口类的注册信息间接建立。你手里有一个HWND想反查它属于哪个模块可以这样操作// 方法一GetWindowLongPtr 取 GWLP_HINSTANCE HINSTANCE hInst (HINSTANCE)GetWindowLongPtr(hwnd, GWLP_HINSTANCE); // 方法二GetClassLongPtr 取 GCLP_HINSTANCE查询注册类时的模块句柄 HINSTANCE hInstClass (HINSTANCE)GetClassLongPtr(hwnd, GCLP_HINSTANCE);这两种方式拿到的值在大多数情况下是一样的。但要注意GWLP_HINSTANCE拿到的实际上是创建窗口时传入的那个hInstance它是窗口对象的一个附加字段在CreateWindowEx时被写入。而GCLP_HINSTANCE是注册时写入窗口类结构里的模块句柄。如果创建时按规矩传了正确的hInstance两者就一致。有个例外要特别注意系统预定义控件类比如BUTTON、EDIT、STATIC这些它们是在系统模块user32里注册的。你用GetWindowLongPtr(hwndOfButton, GWLP_HINSTANCE)拿到的往往是user32的模块句柄而不是你的程序句柄。所以如果你要根据某个控件的HWND找你的程序的模块句柄这条路是行不通的必须绕道FindWindow之类的方法或者老老实实在创建控件时自己记录下来。5. 实操场景从入口函数到窗口跑起来的完整链路5.1 入口函数的hInstance应该怎么藏写Win32程序的第一行有效代码通常就是把WinMain的hInstance参数保存起来。因为之后你会在很多地方用到它注册窗口类、创建主窗口、加载图标、创建对话框。如果等到要用的时候再找要么得把参数层层传递要么就得依赖GetModuleHandle都不如一开始就存进全局变量省事。我自己习惯这样写HINSTANCE g_hInst NULL; int APIENTRY wWinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance, LPWSTR lpCmdLine, int nCmdShow) { UNREFERENCED_PARAMETER(hPrevInstance); UNREFERENCED_PARAMETER(lpCmdLine); g_hInst hInstance; // 后续注册窗口类、创建窗口都用 g_hInst // ... }这个g_hInst全局变量的作用范围是整个进程生命周期。只要EXE被加载这个值就一直有效。所以你在任何函数里都可以放心地使用它。不少公司内部风格规范里也确实默认要求窗口程序保存一个全局实例句柄。如果你写的是控制台程序没有WinMain怎么办没关系可以直接调用GetModuleHandle(NULL)它返回的就是进程主模块也就是那个EXE的句柄和WinMain收到的hInstance一模一样。5.2 注册窗口类hInstance填错一次就知道疼我认识一个朋友当年在DLL里做插件界面注册窗口类时填了主程序的hInstance结果一切正常。后来他把代码搬到另一个不含该窗口类的宿主程序里插件怎么加载都失败。查了很久最后发现是窗口类注册到主模块名下宿主程序换了一个窗口类也跟着消失了。这说明什么说明你注册窗口类时填的hInstance一定要是自己的模块句柄而不是宿主程序的句柄。如果你在DLL里写界面代码DllMain收到的hModule就是正确的hInstance。你应该把它保存为全局所有注册窗口类和创建对话框的操作都用这个值。反过来如果你的界面代码在主程序EXE里那就用GetModuleHandle(NULL)或者WinMain的hInstance。这里再补充一个技巧如果同一个DLL被加载多次用LoadLibrary显式加载且没有使用LOAD_LIBRARY_AS_DATAFILE之类的特殊标志系统通常返回同一个模块基址所以你的DLL全局hInstance保持稳定。但这并不意味着你可以在DLL卸载之后再继续用它DLL被FreeLibrary卸载之后模块基址立刻就变成无效的内存地址任何试图通过它加载资源的操作都会失败甚至崩溃。5.3 创建窗口与对话框模板模块不匹配的后果创建窗口的代码我们再细化看一下重点观察最后一个参数hInstance和窗口类名的配合// 注册hInstance g_hInst RegisterClassEx(wcex); // 创建最后一个参数也是 g_hInst HWND hwnd CreateWindowEx(0, LMyWindowClass, LHello, WS_OVERLAPPEDWINDOW, 0, 0, 800, 600, NULL, NULL, g_hInst, NULL);这套组合拳打好了程序正常运行。如果把CreateWindowEx的hInstance写成其它模块的句柄系统找不到窗口类返回NULLGetLastError告诉你ERROR_CLASS_DOES_NOT_EXIST。对话框比普通窗口更依赖HINSTANCE。DialogBoxParam的第一个参数是HINSTANCE它是用来定位模板资源的。如果你把主程序的hInstance传给一个需要从DLL加载对话框模板的函数而DLL里有IDD_SETTING对话框主程序里没这个资源那么DialogBoxParam立即返回-1什么对话框都不会弹出来。附带一提很多界面库封装了对话框内部会自己去取模块句柄所以外面看不出问题。可一旦你自己写原生代码模块不匹配的问题就会原形毕露。5.4 在DLL里做UI的特别注意事项在DLL中创建窗口或对话框与在EXE中有一个微妙区别DLL的HINSTANCE默认基址和EXE不同而且DLL可能被多个加载者共享。最稳妥的做法是在DLL_PROCESS_ATTACH分支里把hModule保存起来HINSTANCE g_hDllInst NULL; BOOL APIENTRY DllMain(HMODULE hModule, DWORD ul_reason_for_call, LPVOID lpReserved) { switch (ul_reason_for_call) { case DLL_PROCESS_ATTACH: g_hDllInst (HINSTANCE)hModule; break; case DLL_PROCESS_DETACH: g_hDllInst NULL; break; } return TRUE; }之后DLL里所有注册窗口类、加载图标、创建对话框的操作全部使用g_hDllInst。另外一个容易忽略的点DLL中创建的窗口其窗口过程处理函数必须位于DLL的代码段中这个没什么问题但是DLL卸载时如果窗口还没销毁那窗口过程所在的内存就会被释放窗口再次接收消息时就会崩溃。所以必须在DLL_PROCESS_DETACH之前确保所有窗口已销毁或者妥善处理引用计数。我在实际插件开发中踩过一次插件DLL被宿主程序卸载但我的窗口还开着。宿主卸载DLL后立即崩溃。排查了挺久最后加上卸载前销毁所有窗口的生命周期管理逻辑才解决。这虽然和HINSTANCE不直接相关但都属于模块生命周期和窗口生命周期必须匹配这个大主题。6. 常见问题与排查技巧实录6.1 新手最容易翻的车我见过太多初学者的代码翻车隔着屏幕都能闻到烧焦的味道。这里整理几种高频事故每个都是亲历或者身边人踩过的。第一类用CreateWindow返回的HWND去当HINSTANCE用。比如有人想加载一个图标却把CreateWindowEx的返回值传给LoadIcon当第一个参数。编译不报错运行时图标加载不出来或者加载出个乱七八糟的东西。根本原因就是HWND和HINSTANCE虽然都是句柄但一个是窗口对象的门牌号一个是模块的基地址完全不搭边。第二类CreateWindowEx最后一个参数传NULL。如果在注册窗口类之后窗口类归属于你的模块传NULL就找不到该类创建失败。新手常觉得最后一个参数无所谓实际相当有所谓。第三类对话框函数用错模块句柄。程序启动时存了EXE的hInstance然后在一个DLL的代码里调用DialogBoxParam传EXE的hInstance。对话框直接打不开GetLastError返回ERROR_RESOURCE_NOT_FOUND。这种情况在插件编程里特别常见因为我见过不止一个插件开发者把主程序的hInstance带进插件的对话框逻辑里。第四类在程序里用GetModuleHandle(L某个DLL)时传入不带扩展名或带错扩展名的名字返回NULL后没有检查直接传NULL给LoadIcon等函数导致程序行为混乱。第五类窗口销毁后继续拿着HWND调用SendMessage。窗口已经销毁HWND失效SendMessage可能返回0也可能直接触发一个异常。如果你在消息处理函数里对WM_DESTROY之后的窗口操作不加以防护很容易遇到偶现崩溃。6.2 排查工具和思路遇到HWND或HINSTANCE相关问题我喜欢按以下顺序排查效率最高。第一步确认句柄类型是否正确。在调试器的Watch窗口里把表达式写成(HMODULE)0x12345678和(HWND)0x12345678看看两边哪个看起来正常。如果某个API要求HWND但你传了HINSTANCE类型检查一眼就能看出来。第二步检查模块路径。如果出现资源找不到或窗口类不存在先确认传入的HINSTANCE对应的模块是不是你预期的那一个。可以在代码里临时加一句wchar_t path[MAX_PATH] {0}; GetModuleFileName(hInstance, path, MAX_PATH); OutputDebugString(path);打印出来看看这个模块到底是谁。第三步核对窗口类注册信息的全局状态。用GetClassInfoEx(hInstance, LMyWindowClass, wcex)检查窗口类是否注册成功以及窗口类归属的hInstance和你CreateWindowEx传入的是不是一个。第四步用SPY验证HWND是否有效。SPY可以看到系统当前所有顶层窗口的句柄值、类名、标题、进程ID。如果窗口已创建但找不到说明创建失败了如果窗口存在但你的代码拿不到说明查找逻辑有偏差。我还有一个土办法写日志时把HWND和HINSTANCE都按十六进制打印出来然后在日志里比对值。实际开发中这是最快定位的方式。6.3 一套可以抄作业的检查清单这里是我自己总结的一个检查清单每次基于HWND和HINSTANCE的代码出问题我都会按上面的顺序过一遍。你也可以直接把这个抄下来贴在显示器旁边。第一项窗口类注册。检查WNDCLASSEX里的hInstance是不是当前模块句柄。检查窗口类名是否拼写一致尤其注意大小写和宽窄字符。第二项窗口创建。检查CreateWindowEx的类名字符串是否与注册时一致最后一个hInstance是否与注册时一致父窗口HWND是否有效。第三项对话框创建。检查DialogBoxParam的hInstance是否包含你想要的对话框模板资源。模板ID的类型是LPCTSTR还是MAKEINTRESOURCE是否有冲突。第四项DLL内创建UI。确认DllMain里保存了hModule且没有在DLL卸载后继续使用。确认窗口所有者在DLL卸载前销毁。第五项消息处理。不要在WM_DESTROY之后再操作窗口。如果窗口可能被外部销毁使用消息钩子或弱引用的方式管理HWND。这份清单看着简单但80%的相关问题都能被它揪出来。7. 最后分享一个小技巧这篇文章推动到这个位置核心内容基本讲完了。最后我再分享一个自己用得很顺手的习惯算是一个提升效率的小技巧。我写窗口程序时喜欢定义一个模块上下文结构体把每个模块的HINSTANCE、窗口类名、主题资源ID都收拢到一起。比如struct ModuleUiContext { HINSTANCE hInstance; LPCWSTR windowClassName; LPCWSTR dialogTemplateName; int iconResourceId; }; ModuleUiContext g_mainUi { (HINSTANCE)GetModuleHandle(NULL), LMainWindowClass, MAKEINTRESOURCE(IDD_MAIN), IDI_MAIN_ICON };之后所有注册类、创建窗口、加载资源的函数都以这个结构体为参数模块句柄从哪里来传到哪里去一清二楚。这个习惯帮我避开了很多找到窗口类却加载错了图标对话框模板和模块不配套之类的问题。尤其是在做插件系统或者多模块UI的时候这个结构的优势非常明显。总结成一句话HWND是窗口的门牌号HINSTANCE是模块的基址窗口要存活门牌号才有效模块要加载基址才能用。搞清这条主线Windows窗口编程的底子就算真正打扎实了。