MFC全局钩子实践：跨窗口监听键盘与鼠标事件

简介：面向 Windows C++ 开发者的 MFC 全局钩子示例项目，演示如何结合 MFC 对话框程序与 HOOK.DLL，通过 SetWindowsHookEx 设置全局键盘/鼠标钩子，实时捕获按键码和鼠标位置等输入信息，并写入日志文件。资源包含完整 Visual Studio 工程源码，涉及低层钩子、DLL 注入、对话框控件更新和文件输出等关键知识点，适合学习 Windows 消息机制和钩子技术的初中级开发者参考实践。压缩包共 80 个文件，约 66.54MB，以 C++ 源文件、头文件、rc 资源、解决方案及可执行程序、动态库为主，同时附有 PDB 调试符号与编译中间文件，便于在 Debug 或 Release 模式下直接编译、运行和调试。目前已收录 1397 人学习，读者可通过源码和程序对照理解全局钩子的整个工作流程，也可借助工程结构快速定位钩子处理函数、MFC 界面交互和文件写逻辑等核心模块，节省自行搭建环境的时间。 去年做远程协助工具的时候，客户在办公室一台老机器上录数据，每个窗口都要手动切过去输入一遍，几轮操作下来特别容易漏。后来我一咬牙给工具加了一个 MFC 全局钩子模块，把键盘输入和鼠标输入统一收进来监听、记录，问题当场解决。那之后我陆续用这套思路做了快捷键启动器、鼠标宏录制、无障碍辅助输入，效果都很稳。如果你也正在做 MFC 程序，需要一个能跨窗口监听键盘和鼠标事件的全局钩子，这篇笔记值得你看完。

我会从钩子的分类说起，因为这里最容易出岔子；然后给出可以直接抄的键盘钩子和鼠标钩子完整实现；最后整理一份我自己反复踩坑后沉淀下来的排查清单。整个过程不绕弯子，代码基于 VS2013 的 MFC 编写，换了 VS2019、VS2022 一样能跑，底层 API 这些年没大变过。

1. 先别急着写代码：钩子家族里藏着两个容易弄混的东西

1.1 全局钩子靠 DLL 注入，但低级钩子是个例外

很多人一听“全局钩子”，第一反应就是“那我得写一个 DLL，然后注入到所有进程里”。这个说法对传统钩子成立，对低级钩子（Low-Level Hook）不成立，而绝大多数现代应用场景用的恰恰是低级钩子。

传统钩子WH_KEYBOARD（值 2）和WH_MOUSE（值 7）如果要全局生效，系统会把你的钩子 DLL 注入到每一个有消息队列的进程中，然后在各个进程里分别调用你的回调函数。这样一来，调试就变成了一场噩梦：你没法直接在 VS 里单步跟踪，只能靠 OutputDebugString 输出日志，或者额外挂一个调试器到目标进程上。而且 DLL 注入本身有风险，目标进程如果正处在加载锁之类的敏感状态，注入失败或者崩溃都是常见事。

低级钩子则完全不同。WH_KEYBOARD_LL（值 13）和WH_MOUSE_LL（值 14）的回调函数，是在安装钩子的那个线程上下文里执行的，不需要注入任何 DLL。系统把输入事件传递给目标窗口之前，先塞进你安装钩子的那个线程队列里，由你的消息循环把事件“捎带”出来，调用你的钩子回调。这带来的直接好处是：你可以用单个 EXE 完成全局输入监听，调试体验和普通线程回调几乎一样。

1.2 低级钩子和传统钩子的取舍

从我个人的实际体验来说，除非你明确知道自己需要和某个进程内部的消息机制深度交互，否则优先选低级钩子。理由很简单：不用 DLL，单 EXE 搞定；回调在自己的进程里，出问题能快速定位；卸载钩子时也不用担心 DLL 在别的进程里没有被正确释放的老问题。

1.3 低级钩子也有自己的脾气

低级钩子回调是“借用”你当前线程的消息循环来执行的，所以你的线程必须持续处理消息。如果消息循环卡住，钩子回调就不会被触发，看起来就是“钩子没生效”。另外回调里绝不能做耗时操作，系统对低级钩子回调有硬性超时限制，一旦超时，系统会静默地把你的钩子摘掉，连个报错都不给。这两点在后面排查章节会展开细说。

2. 工程搭建的几个细节：配置不对，钩子装上了也是摆设

2.1 一个干净的最小工程长什么样

我建议直接用 VS 创建“MFC 对话框应用”，工程名随意，字符集选择“使用 Unicode 字符集”。为什么是 Unicode？因为钩子回调里拿到的虚拟键码、扫描码都是编码无关的，主窗口消息最好统一用宽字符，省得后期拼接字符串时出现乱码。如果你手头有老工程是多字节字符集，也能跑，但新项目我强烈建议 Unicode。

新建完工程后，你会得到一个默认的CMyApp和CMyDlg。钩子的安装时机有几个选择：对话框的OnInitDialog、应用程序类的InitInstance，或者某个按钮事件。我在实践中最常用的是OnInitDialog里安装，WM_DESTROY里卸载，因为对话框是主窗口，生命周期好控制。

2.2 消息循环对低级钩子意味着什么

低级钩子依赖消息循环，这一点怎么强调都不过分。MFC 程序的CWinApp::Run()内部本来就有GetMessage/TranslateMessage/DispatchMessage循环，所以对话框程序天然满足条件。但如果你图省事，用控制台程序测试低级钩子，就千万记得自己补一个消息循环：

MSG msg; while (GetMessage(&msg, NULL, 0, 0)) { TranslateMessage(&msg); DispatchMessage(&msg); }

否则SetWindowsHookEx返回的句柄看起来没问题，但回调永远不触发。新手在这里卡半天的情况我见得太多了——不是钩子没装上，是线程根本没有消息泵。

2.3 安装与卸载必须成对出现

安装钩子用的是SetWindowsHookEx，这个函数的四个参数值得你说个清清楚楚：

• idHook：钩子类型。键盘用WH_KEYBOARD_LL（13），鼠标用WH_MOUSE_LL（14）。
• lpfn：回调函数指针。
• hMod：包含回调函数的模块句柄。低级钩子直接传GetModuleHandle(NULL)即可，因为回调就在 EXE 里。
• dwThreadId：为 0 表示关联系统所有线程，也就是全局钩子。

对应的卸载函数是UnhookWindowsHookEx，传安装时拿到的HHOOK句柄。这里有一个隐含规则：安装和卸载最好在同一个线程里完成。低级钩子的回调在安装线程上下文执行，如果跨线程卸载，可能造成回调还没执行完，钩子对象已经被释放，轻则访问违例，重则程序直接崩掉。

我自己的做法是写一个钩子管理类，安装和卸载都封装到类里，用同一个线程调用。比如在OnInitDialog里调用Start()，在OnDestroy里调用Stop()，这两个方法都发生在主线程，符合规则。

2.4 让钩子活得久一点：生命周期管理

实际项目中钩子不是装一次就完了。窗口可能重建，对话框可能被关闭再打开，如果每次都重新安装而不卸载旧的，会产生钩子泄漏。另外多个模块可能共用一个钩子管理对象，这时候最好在类里加一个引用计数或者运行状态标志，避免Start()被调用两次导致重复安装。

简单粗暴的做法是：Start()里先调用Stop()清理旧的，再安装新的。这样窗口任意重建多少次都没问题。

3. 键盘钩子实现：从安装到把按键数据送到 UI

3.1 键盘回调的骨架代码

键盘钩子的核心就两个部分：安装钩子、写回调。下面这段代码我反复用了两年，稍微改动就能适配不同需求。

#pragma once class CGlobalInputHook { public: static CGlobalInputHook* Instance(); // 简单单例 BOOL Start(HWND hNotifyWnd); BOOL Stop(); private: static LRESULT CALLBACK KeyboardProc(int nCode, WPARAM wParam, LPARAM lParam); static LRESULT CALLBACK MouseProc(int nCode, WPARAM wParam, LPARAM lParam); HWND m_hNotifyWnd; // 通知窗口，用于转发消息 HHOOK m_hKeyboardHook; HHOOK m_hMouseHook; };

安装接口的典型实现如下：

BOOL CGlobalInputHook::Start(HWND hNotifyWnd) { Stop(); // 防止重复安装 m_hNotifyWnd = hNotifyWnd; m_hKeyboardHook = SetWindowsHookEx( WH_KEYBOARD_LL, KeyboardProc, GetModuleHandle(NULL), 0); m_hMouseHook = SetWindowsHookEx( WH_MOUSE_LL, MouseProc, GetModuleHandle(NULL), 0); return (m_hKeyboardHook && m_hMouseHook); } BOOL CGlobalInputHook::Stop() { if (m_hKeyboardHook) { UnhookWindowsHookEx(m_hKeyboardHook); m_hKeyboardHook = NULL; } if (m_hMouseHook) { UnhookWindowsHookEx(m_hMouseHook); m_hMouseHook = NULL; } return TRUE; }

你需要自己保证KeyboardProc和MouseProc是静态函数或者全局函数，因为回调函数指针不能指向非静态成员函数。静态函数里访问成员变量没有任何问题，钩子管理类本身就是单例，访问静态实例指针即可。

3.2 KBDLLHOOKSTRUCT 里能拿到什么

回调函数的参数lParam指向一个KBDLLHOOKSTRUCT结构体：

typedef struct tagKBDLLHOOKSTRUCT { DWORD vkCode; // 虚拟键码，如 VK_F1、'A' DWORD scanCode; // 硬件扫描码 DWORD flags; // 状态标志 DWORD time; // 事件时间戳 ULONG_PTR dwExtraInfo; // 附加信息 } KBDLLHOOKSTRUCT;

我用得最多的是vkCode，用来判断具体按了哪个键。flags也很重要，其中LLKHF_ALTDOWN（0x20）表示 Alt 键是否被按下，LLKHF_EXTENDED（0x01）表示是不是扩展键（比如右 Ctrl、小键盘回车），LLKHF_INJECTED（0x10）表示事件是不是由SendInput之类的方法注入的——这个字段在做输入回放时特别有用，可以用来区分“真实按键”和“脚本模拟按键”。

回调的wParam参数则表示事件类型：

• WM_KEYDOWN：普通按下
• WM_KEYUP：普通抬起
• WM_SYSKEYDOWN：Alt 组合键按下
• WM_SYSKEYUP：Alt 组合键抬起

我的键盘回调通常是这样的：

LRESULT CALLBACK CGlobalInputHook::KeyboardProc(int nCode, WPARAM wParam, LPARAM lParam) { if (nCode == HC_ACTION) { KBDLLHOOKSTRUCT* pKb = (KBDLLHOOKSTRUCT*)lParam; if (wParam == WM_KEYDOWN || wParam == WM_SYSKEYDOWN) { // 只做轻量处理，把数据转发给主窗口 ::PostMessage(m_hNotifyWnd, WM_APP_KEYBOARD, (WPARAM)pKb->vkCode, (LPARAM)pKb->flags); } } return CallNextHookEx(NULL, nCode, wParam, lParam); }

注意我传的是结构体的字段值，不是结构体指针。低级钩子回调返回后，lParam指向的那块内存后续会被系统重新使用，所以绝对不要把这个指针缓存下来。跨线程回消息时更是如此。

3.3 怎么过滤按键、怎么把数据传回主窗口

过滤按键是键盘钩子最常用的场景之一，比如想做全局快捷键，希望按下某个组合键时不把按键事件继续传给其他窗口。做法很简单：在回调里返回一个非零值，系统就会认为这个消息已经被处理掉了，目标窗口收不到任何按键事件。

举个例子，屏蔽A键：

if (pKb->vkCode == 'A') { return 1; // 吞掉这个按键 }

但我要提醒一句：return 1返回的是整个KeyboardProc的返回值，不是单独一个字段。所以过滤逻辑一定要写在CallNextHookEx之前，一旦决定吞掉，就不该再调用CallNextHookEx。

把数据传回主窗口，最安全的手段是PostMessage。它是异步的，不会在当前线程里等待目标窗口处理完消息，也就不会和主窗口产生死锁。如果需要传多个数据，可以用WPARAM传键码、LPARAM传状态标志，零拷贝零分配，性能最好。数据量大了以后可以考虑自定义一个结构体，自己管理内存，但那是后话，初期数值传递完全够用。

4. 鼠标钩子实现：点击、移动、滚轮全覆盖

4.1 鼠标回调的结构体与事件映射

鼠标钩子的安装方式和键盘钩子一模一样，区别在回调函数和结构体。MSLLHOOKSTRUCT长这样：

typedef struct tagMSLLHOOKSTRUCT { POINT pt; // 屏幕坐标 DWORD mouseData; // 滚轮增量或 X 按钮值 DWORD flags; // 事件标志 DWORD time; // 时间戳 ULONG_PTR dwExtraInfo; // 附加信息 } MSLLHOOKSTRUCT;

鼠标事件通过wParam区分，常用的事件有：

• WM_MOUSEMOVE：移动
• WM_LBUTTONDOWN/WM_LBUTTONUP：左键按下/抬起
• WM_RBUTTONDOWN/WM_RBUTTONUP：右键按下/抬起
• WM_MBUTTONDOWN/WM_MBUTTONUP：中键按下/抬起
• WM_MOUSEWHEEL：滚轮滚动
• WM_XBUTTONDOWN/WM_XBUTTONUP：侧键按下/抬起

回调代码如下：

LRESULT CALLBACK CGlobalInputHook::MouseProc(int nCode, WPARAM wParam, LPARAM lParam) { if (nCode == HC_ACTION) { MSLLHOOKSTRUCT* pMouse = (MSLLHOOKSTRUCT*)lParam; switch (wParam) { case WM_LBUTTONDOWN: ::PostMessage(m_hNotifyWnd, WM_APP_MOUSE, (WPARAM)WM_LBUTTONDOWN, MAKELPARAM(pMouse->pt.x, pMouse->pt.y)); break; case WM_MOUSEMOVE: // 移动事件非常频繁，可以加个节流 break; } } return CallNextHookEx(NULL, nCode, wParam, lParam); }

MAKELPARAM把坐标压缩到LPARAM里，主窗口收到后可以用GET_X_LPARAM和GET_Y_LPARAM解出来，或者直接LOWORD/HIWORD。这种攒两数到一参的做法很老派，但到现在依然好用，而且避免了跨线程传结构体的内存管理问题。

4.2 从 mouseData 里取滚轮方向和增量

滚轮是鼠标钩子里比较容易写错的地方。mouseData是一个 DWORD，但滚轮增量只在高 16 位里，而且是带符号的。正确做法是把高 16 位取出来强转成 short：

short zDelta = (short)HIWORD(pMouse->mouseData); // 正数向上滚，负数向下滚 if (zDelta > 0) // 向上滚 else // 向下滚

很多新人直接拿mouseData当整数判断，结果永远进不了分支，排查半天才发现是符号问题。顺手提一句：mouseData的另一个用途是 X 按钮，高 16 位是XBUTTON1或XBUTTON2，对应侧键的按下事件，这个在办公软件自动化场景里偶尔会用到。

4.3 坐标、状态标记和注入检测

pt是屏幕坐标，不是窗口客户区坐标。如果主窗口需要判断鼠标落在哪个窗口上，可以用WindowFromPoint。事件过滤和键盘钩子一样，return 1即可吞掉某个鼠标事件，比如屏蔽指定区域内的左键点击。

flags字段里最有用的是LLMHF_INJECTED（0x01），表示这个鼠标事件是不是由SendInput等模拟操作注入的。我当初做鼠标宏回放时，就用它来区分真实鼠标操作和模拟回放，避免回放过程中再次触发录像逻辑，形成无限循环。实测很有效，建议你也留个心眼。

5. 钩子不生效？我的排查清单按顺序抄就行

5.1 第一查：消息循环是不是真的在轮询

低级钩子不生效的头号原因不是安装失败，而是线程没有消息循环。我的排查顺序如下：

1. 确认当前线程是不是 UI 线程。MFC 对话框主线程是 UI 线程，天然有消息循环。
2. 如果在工作线程里安装钩子，必须自己写GetMessage循环。
3. 如果主窗口进入模态框循环（比如DoModal），钩子依然能触发，因为模态框内部也有消息循环。但如果你的代码在某个while死循环里不出来，消息泵停了，钩子就彻底失效。

最快的验证手段是在回调开头放一句OutputDebugString，配合 Sysinternals 的 DebugView 看输出。如果一句都没出来，大概率就是消息循环的问题。

5.2 第二查：位数、权限和杀毒软件

这里是三个容易混淆的问题，我分开说。

位数问题是最容易被忽略的。64 位系统上，32 位进程安装的低级钩子只能收到 32 位进程的输入事件，钩不到 64 位进程（比如很多新版浏览器、资源管理器都是 64 位）。反过来也一样。所以如果你的 MFC 程序是 32 位编译，而你想监听的目标是 64 位程序，结果是听了个寂寞。解决方案要么把主程序编成 64 位，要么同时跑一个 32 位和一个 64 位的协作进程。

权限问题也很现实。如果目标窗口以管理员权限运行，你的普通权限钩子进程收不到对应事件。开发调试遇到这种情况，直接把 VS“以管理员身份运行”，最省心。发布时可以在 manifest 里声明requireAdministrator，效果差不太多。

杀毒软件和安全卫士是第三方变量。360、腾讯管家这类软件对全局钩子非常敏感，安装钩子时可能弹窗拦截，行为分析也可能把钩子识别成键盘记录器。我开发期间的习惯是：测试机暂时关闭实时防护，把程序加入白名单，跑通之后再重新开启，逐个确认告警原因。如果你的程序是正经业务工具，建议准备一份给安全软件厂商的说明文档，签名证书能有效降低误报率。

5.3 第三查：回调超时与“被系统悄悄卸载”

这是我踩得最深的一个坑。Windows 对低级钩子回调有超时限制，默认值在较新系统上大约是 1000~3000 毫秒（取决于注册表LowLevelHooksTimeout）。也就是说，如果回调函数里一次执行超过这个阈值，系统会认为钩子已经失去响应，悄悄把钩子摘掉，而且不产生任何错误码。

你回头看自己的代码，如果回调里写了Sleep、WaitForSingleObject、或者大循环解析数据、或者调用SendMessage等待跨进程响应，那都是在雷区里走。我的处理原则是：

• 回调里只做数据采集，不写日志、不弹框、不做网络请求。
• 回调里一律用PostMessage异步通知主窗口，绝不使用SendMessage同步等待。
• 数据量大时，先用一个环形缓冲区暂存，让主线程定时批量消费。

5.4 回调里禁止做的事：SendMessage 和 Sleep 是重灾区

死锁是低级钩子最容易出现的深坑，具体场景是这样的：你的钩子回调里调用SendMessage给主窗口发消息，而主窗口恰好也在等某个输入事件完成，或者主窗口当前正卡在某个模态循环里，结果主窗口不处理你的SendMessage，你的钩子回调又停在SendMessage里不返回，系统超时后直接把钩子摘掉，整个功能瘫痪。

要避免这个问题很简单：跨线程通知一律PostMessage。记住这句话，能少踩 80% 的坑。

另外一个经验：回调里不要调用可能触发输入事件再处理逻辑的函数，比如SendInput。这会引起递归，轻则性能雪崩，重则栈溢出。如果你要在钩子回调里做输入回放，一定要用上一节提到的LLMHF_INJECTED/LLKHF_INJECTED标志做递归防护。

6. 这套钩子还能往哪走：从我项目里沉淀出的几个扩展方向

键盘钩子和鼠标钩子整套跑通之后，能干的事情比我最初预想的多得多。我这里分享几个自己做过的扩展，都是基于同一套钩子管理类改出来的。

第一是全局快捷键管家。在键盘回调里维护一个组合键状态表，按下Ctrl+Shift+Q之类组合时，PostMessage给主窗口发自定义消息，主窗口再执行对应动作。这样不管焦点在哪个程序里，快捷键都能全局生效。

第二是鼠标宏录制回放。键盘回调里记录按键时间戳和键码，鼠标回调里记录点击位置、滚轮增量和时间戳，回放时用SendInput按顺序执行。回放时靠LLKHF_INJECTED和LLMHF_INJECTED做防递归判断，这个我前面提过，是最关键的细节。

第三是无障碍辅助输入。比如为特定用户过滤误触按键，屏蔽短时间内重复点击，或者把长按和短按区分出来映射成不同操作。这类需求在做客户定制软件时很常见，钩子模块基本不用改，改的是事件处理策略。

第四是输入统计工具。在回调里统计按键频率、活跃时间段，数据可以缓存在本地文件里，或者直接通过局域网发送到可视化面板。用途可以很正经，比如团队办公效能分析。但这块涉及用户隐私，务必在合法授权场景下使用，尊重使用者知情权，别越界。

我现在的工程结构基本固定了：一个CGlobalInputHook单例负责钩子生命周期管理，回调里只做事件采集和PostMessage，所有业务逻辑都放在主窗口的消息处理函数里。加新功能时，只改消息处理那一层，钩子层几乎不动。如果你想在项目里快速落地，强烈建议也采用这个分层思路，一上来就把键盘鼠标两个钩子全写完再联调，调试成本会高很多。先跑通键盘，再叠加鼠标，最后再加过滤规则，整个流程能压缩在一个小时以内。

最后再分享一个小技巧：开发阶段把OutputDebugString日志保留在回调入口处，出问题时 DebugView 扫一眼就知道回调到底有没有进来、进入了哪个分支。发布版本再把这行注释掉，避免无谓的开销。这套做法我用了很多年，比什么花哨的调试工具都直接。

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