全局键盘钩子必须在DLL中实现，不能直接在EXE中编写，因EXE地址空间不共享，需通过SetWindowsHookEx将DLL注入各进程；WH_KEYBOARD_LL钩子要求hInstance为DLL自身句柄，回调函数须extern "C" __declspec(dllexport)导出，拦截按键返回非零值，放行则调用CallNextHookEx；钩子函数内禁用耗时操作，通过KBDLLHOOKSTRUCT获取vkCode等信息，结合GetKeyState判断修饰键；卸载时须避免提前FreeLibrary，应在DLL_PROCESS_DETACH且非热加载时调用UnhookWindowsHookEx；64位程序无法监控32位进程按键，需分架构部署x86/x64两套DLL并独立管理。
Windows平台下用SetWindowsHookEx注册全局键盘钩子
全局键盘钩子必须在DLL中实现，不能直接在EXE里写——因为SetWindowsHookEx要求钩子过程（LowLevelKeyboardProc）被所有目标进程加载并调用，而EXE的地址空间不共享。你得编译成DLL，并确保它能被系统注入到其他进程。
关键点：HHOOK hHook = SetWindowsHookEx(WH_KEYBOARD_LL, LowLevelKeyboardProc, hInstance, 0); 中第四个参数为0表示全局钩子（对所有线程生效），但前提是DLL已正确加载且hInstance是DLL自身的实例句柄（不是主EXE的）。
-
LowLevelKeyboardProc必须声明为extern "C" __declspec(dllexport)，避免C++名字修饰导致系统找不到入口 - 钩子函数返回值：若想拦截按键（不让后续程序收到），必须返回非零值；若放行，应调用
CallNextHookEx并返回其结果 - 不要在钩子函数里做耗时操作（如文件I/O、弹窗、复杂计算），否则会卡住整个UI线程
钩子函数里如何安全读取按键状态和虚拟键码
在LowLevelKeyboardProc回调中，lParam指向KBDLLHOOKSTRUCT结构体，其中wParam是消息类型（WM_KEYDOWN/WM_KEYUP），vkCode是虚拟键码，scanCode是扫描码。
注意：vkCode不能直接等同于字符（比如按Shift+A得到的是VK_A，不是'A'），也不反映当前键盘布局下的实际字符。需要转义或组合判断时，要用GetKeyState或MapVirtualKey辅助：
立即学习“C++免费学习笔记（深入）”；
-
GetKeyState(VK_SHIFT) & 0x80判断Shift是否按下（高位为1表示按下） -
MapVirtualKey(vkCode, MAPVK_VK_TO_CHAR)仅对部分键有效，且不考虑修饰键，慎用 - 区分重复触发：检查
lParam->flags & LLKHF_REPEAT位，可跳过自动重复的WM_KEYDOWN
卸载钩子时常见崩溃原因和规避方式
调用UnhookWindowsHookEx(hHook)失败或时机不对，会导致钩子残留、DLL无法卸载，甚至目标进程崩溃。最典型问题是：钩子还在运行时就FreeLibrary了DLL。
解决方案是让DLL自己管理生命周期，而不是靠主程序随意释放：
- 用
DisableThreadLibraryCalls(hInst)禁用DLL_THREAD_ATTACH/DETACH通知，减少干扰 - 在DLL_PROCESS_DETACH分支中，只在
dwReason == DLL_PROCESS_DETACH && !lpReserved时才尝试卸载钩子（即非热加载场景） - 主程序调用卸钩函数前，确保所有线程已退出钩子回调——可加简单计数器或事件同步，但别用锁阻塞钩子函数本身
64位程序钩子无法捕获32位进程按键的兼容性问题
Windows不允许跨架构注入：64位DLL不能注入到32位进程，反之亦然。如果你的主程序是64位，但想监控Chrome（32位）、微信（32位）等，WH_KEYBOARD_LL钩子会失效——它看似注册成功，但根本不会被32位进程调用。
没有银弹方案，只能分架构部署：
- 写两套DLL（x86和x64），分别由对应位数的控制程序加载
- 主控程序需检测目标进程位数，再决定加载哪个DLL版本
-
GetNativeSystemInfo和IsWow64Process可用于判断，但注意：即使系统是64位，GetCurrentProcess也可能返回32位句柄
真正难处理的是混合环境：用户同时开着32位和64位应用，你得维持两个钩子实例，各自独立管理，且不能共用同一块共享内存——不同架构间内存不可互访。
