必须用WH_KEYBOARD_LL钩子拦截键盘输入，因其在系统级截获所有按键（含Win+R），而普通WH_KEYBOARD需DLL注入且无法捕获全局热键；回调中通过KBDLLHOOKSTRUCT的flags判断按键状态，屏蔽需返回非零值，放行则调用CallNextHookEx；常见失败原因包括导出声明缺失、钩子句柄未全局保存、未正确卸载及阻塞式操作。
不能靠 cin 或 getchar 屏蔽键盘输入——它们只管读，不管拦。真要拦截或过滤按键，必须用 Windows 低级键盘钩子（WH_KEYBOARD_LL），在消息进入目标线程前截住它。
为什么 SetWindowsHookEx 必须用 WH_KEYBOARD_LL
普通钩子（如 WH_KEYBOARD）工作在目标线程上下文中，要求钩子 DLL 被注入到每个目标进程，且无法捕获系统级快捷键（如 Win+R、Ctrl+Esc）。而 WH_KEYBOARD_LL 是“低级”钩子，由系统在内核回调时直接调用你的函数，无需 DLL 注入，所有按键事件（包括全局热键）都会路过它：
- 回调函数签名必须是
LRESULT CALLBACK LowLevelKeyboardProc(int nCode, WPARAM wParam, LPARAM lParam) -
nCode为HC_ACTION时才处理；否则必须调用CallNextHookEx -
lParam指向KBDLLHOOKSTRUCT，其中vkCode是虚拟键码，flags & LLKHF_ALTDOWN表示 Alt 是否按下 - 想屏蔽某个键：返回非零值（如
1）；放行则必须调用CallNextHookEx并返回其结果
常见屏蔽失败的三个原因
写完钩子却依然能输入？大概率卡在这几个地方：
- 回调函数没加
__declspec(dllexport)（如果写在 DLL 中）或没用static+ 正确链接（EXE 内实现时）；C++ 编译器 name mangling 会导致系统找不到入口 - 没把钩子句柄存为全局/静态变量，导致函数返回后钩子被自动卸载；
SetWindowsHookEx返回的HHOOK必须一直有效 - 主线程退出前没调用
UnhookWindowsHookEx(hHook)，不仅资源泄漏，还可能引发后续系统行为异常（尤其调试时反复加载卸载钩子）
KBDLLHOOKSTRUCT 怎么判断“真实按键”而非重复/释放
Windows 对长按会持续发 WM_KEYDOWN，但 WH_KEYBOARD_LL 的 wParam 是消息类型，不是虚拟键码——别混淆。真正要看的是 KBDLLHOOKSTRUCT 的 flags 字段：
立即学习“C++免费学习笔记（深入）”；
-
flags & LLKHF_UP→ 键抬起（WM_KEYUP） -
flags & LLKHF_EXTENDED→ 扩展键（如右 Ctrl、AltGr、方向键等） -
flags & LLKHF_INJECTED→ 该事件由SendInput或类似 API 注入，非物理按键（可选择忽略） - 想只拦截“按下一次”的行为？检查
!(flags & LLKHF_UP)且!(flags & LLKHF_REPEAT)（注意：LLKHF_REPEAT并非标准 flag，需自行比对上次时间戳或用GetKeyState辅助判断）
屏蔽后光标卡住、输入法失效怎么办
粗暴 return 1 拦所有 WM_KEYDOWN 很容易破坏系统交互逻辑。比如：
- 屏蔽
VK_TAB但没放行Shift+Tab，会导致焦点切换异常 - 拦截
VK_PROCESSKEY（IME 激活键）会让中文输入法无法弹出候选框 - 某些 UWP 应用或远程桌面会绕过低级钩子，但若你同时禁用了
WM_CHAR级别处理（比如在子类化窗口中拦截），反而造成双重重叠失效
实际做法是：只拦截明确需要的键（如游戏防误触 ESC），其余一律放行；涉及输入法、快捷键、辅助功能的键码（VK_LWIN、VK_RMENU、VK_OEM_*）务必谨慎测试。
低级钩子不是万能开关，它介入太深，稍有不慎就影响系统稳定性。最易被忽略的一点：钩子回调函数必须快进快出——里面不能有 MessageBox、文件 IO、网络请求，甚至避免 new/delete；超时未返回可能触发系统判定为“无响应”，强制卸载钩子。
