windows下无法真正禁用系统热键，但可用wh_keyboard_ll低级键盘钩子提前捕获并过滤，如win+l需判断wparam为wm_keydown或wm_syskeydown且getkeystate(vk_lwin)
Windows平台下用SetWindowsHookEx拦截Win键和Alt+Tab
不能靠普通消息循环（比如WM_KEYDOWN）捕获Win键或Alt+Tab——它们在到达目标窗口前就被系统截走了。必须用全局钩子，且只能是低级键盘钩子（WH_KEYBOARD_LL），它能在按键事件分发前介入。
关键点：钩子过程必须放在DLL里（否则SetWindowsHookEx对全局钩子会失败），且需以管理员权限运行才能可靠拦截系统热键。
-
SetWindowsHookEx(WH_KEYBOARD_LL, ...)的dwThreadId参数传0表示全局钩子 - 钩子回调函数中，对
wParam == WM_KEYDOWN || wParam == WM_SYSKEYDOWN做判断 - 检测
vkCode == VK_LWIN || vkCode == VK_RWIN屏蔽Win键；检测vkCode == VK_TAB且GetKeyState(VK_MENU) & 0x8000为真时屏蔽Alt+Tab - 返回非零值（如1）表示已处理该键，不向下传递；返回
CallNextHookEx结果表示放行
为什么直接调用BlockInput不管用
BlockInput会锁住整个用户输入（包括鼠标），且从Windows Vista起要求调用者有桌面交互权限，普通进程调用会静默失败。它不是“屏蔽特定组合键”的工具，而是粗粒度的输入冻结机制，完全不适合本场景。
-
BlockInput(TRUE)后，连Ctrl+Alt+Del都无效，用户无法恢复操作 - 即使成功，也无法区分Win键和普通按键，更无法单独放过Ctrl+Esc等合法系统键
- 多数情况下返回
FALSE且GetLastError()为ERROR_ACCESS_DENIED
钩子DLL加载失败的常见原因
很多实现卡在DLL没被注入进Explorer或其他前台进程，导致钩子看似安装成功却毫无反应。根本原因是SetWindowsHookEx返回句柄不为NULL，但钩子过程未被调用。
- 确保DLL输出函数用
__declspec(dllexport)导出，且模块定义文件（.def）里声明了HOOKPROC入口 - 主程序和DLL必须同为32位或同为64位，混用会导致
SetWindowsHookEx返回NULL - 不要在DLL的
DllMain里调用SetWindowsHookEx——此时线程上下文不稳定，易崩溃 - 检查
GetModuleHandle是否返回有效句柄；若用LoadLibrary手动加载DLL，要确认路径无空格且不含中文
Alt+Tab被拦截后任务栏预览失效怎么办
单纯拦截VK_TAB + Alt会导致任务栏缩略图、Flip3D等依赖Alt+Tab的UI功能异常。这不是bug，而是Windows设计使然——这些功能底层复用同一套热键分发逻辑。
如果业务必须保留任务栏交互，唯一可行方案是只拦截Win键，放弃Alt+Tab屏蔽；或者改用RegisterHotKey注册自定义快捷键替代，而非劫持系统热键。
真正稳定的方案永远绕不开权衡：要么接受部分系统功能降级，要么放弃全局拦截，转而监控前台窗口并动态禁用对应快捷键（例如仅在全屏游戏时生效）。没有银弹，只有取舍。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
