必须用WH_KEYBOARD_LL钩子拦截Alt+F4，因系统在WM_KEYDOWN前已截断该组合键；需在DLL中实现回调函数，用GetAsyncKeyState判断Alt状态并返回非零值阻止传递，同时确保位数匹配、避免耗时操作以防系统强制卸载。
Windows平台下用SetWindowsHookEx拦截WH_KEYBOARD_LL
Alt+F4 是系统级快捷键，普通窗口消息（比如 WM_KEYDOWN）在它触发关闭逻辑前就已被系统截断，无法通过 PreTranslateMessage 或 WndProc 拦截。真正可行的路径是安装低级键盘钩子，监控全局按键流。
关键点在于：必须用 SetWindowsHookEx 注册 WH_KEYBOARD_LL 类型钩子，且回调函数需在 DLL 中（否则进程退出后钩子失效，还可能引发崩溃）。钩子函数里检查是否为 Alt+F4 组合，是则返回非零值阻止传递。
-
GetAsyncKeyState(VK_MENU)判断左/右 Alt 是否按下（注意：不能只看wParam == VK_F4，必须同时确认 Alt 键状态） - 钩子回调中不要调用
MessageBox、printf等可能触发 UI 或加载模块的操作，容易死锁 - 钩子 DLL 必须显式导出
SetHook和Unhook函数，主程序通过GetProcAddress调用，避免隐式链接导致卸载失败
C++实现时如何避免钩子被系统自动卸载
Windows 对 WH_KEYBOARD_LL 钩子有严格超时机制：如果回调函数执行超过 10ms，系统会强制卸载钩子并标记为“挂起”。这意味着你在钩子里做任何耗时操作（比如文件 I/O、网络请求、复杂计算）都会导致钩子失效，Alt+F4 恢复生效。
- 所有判断逻辑必须极简——仅用
GetAsyncKeyState+ 位运算判断 Alt+F4，其余逻辑（如日志、UI 提示）应通过线程安全队列交给主线程处理 - 钩子 DLL 的入口点
DllMain中禁止调用LoadLibrary、CreateThread等可能引发同步问题的 API - 使用
std::atomic<bool></bool>控制钩子开关，避免多线程竞争导致Unhook失败
Qt 或 MFC 程序中直接拦截的常见误区
很多人试图在 Qt 的 QApplication::notify 或 MFC 的 PreTranslateMessage 里过滤 WM_SYSKEYDOWN + VK_F4，但这是无效的。系统在发送该消息前已决定关闭窗口，拦截只会让界面卡顿或产生残影，不阻止实际关闭行为。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
- Qt 用户若坚持不用钩子，可重写
closeEvent并调用ignore()，但这只能防止窗口关闭，Alt+F4 的按键音和焦点丢失仍会发生，用户体验断裂 - MFC 中重载
OnSysCommand并过滤SC_CLOSE同样无效——该消息在 Alt+F4 触发后才发出，此时窗口已进入销毁流程 - 真正屏蔽必须在按键被系统解释为“关闭命令”之前介入，也就是
WH_KEYBOARD_LL层级
64位程序与32位钩子DLL的兼容性陷阱
如果你的主程序是 x64，却加载了 x86 的钩子 DLL，SetWindowsHookEx 会静默失败（返回 NULL），且 GetLastError 也不报错。这是最常被忽略的兼容性问题。
- 务必保证主程序与钩子 DLL 的位数完全一致：x64 程序只能加载 x64 DLL，x86 程序同理
- Visual Studio 中检查钩子 DLL 的配置：项目属性 → 常规 → 平台工具集 和 配置类型（必须设为“动态库(.dll)”）
- 调试时用 Process Explorer 查看目标进程是否确实加载了你的 DLL，而不是显示 “Not found” 或 “No modules”
钩子函数本身没多少代码，但部署时的位数匹配、线程安全、超时控制这三点，任何一个出错都会让 Alt+F4 看似“没拦住”，其实不是逻辑问题，而是环境没对齐。
