SetWindowsHookEx在.NET 6+易失效，因WH_KEYBOARD_LL需UI线程消息循环，后台线程调用返回0（错误1428）；回调中禁阻塞、禁托管操作；卸载须显式UnhookWindowsHookEx并防GC回收委托。
为什么 SetWindowsHookEx 在 .NET 6+ 上容易失效
因为默认启用了“仅限 Windows 窗体”上下文，且 WH_KEYBOARD_LL 钩子要求调用线程拥有消息循环（即必须是 UI 线程），而 Task.Run 或后台线程直接调用会静默失败，SetWindowsHookEx 返回 0 且 Marshal.GetLastWin32Error() 常为 1428（ERROR_HOOK_NOT_INSTALLED）。
实操建议：
- 钩子安装必须在 WinForms/WPF 主线程中完成，不能放在
async void或Task中 - 确保程序至少有一个隐藏窗体（哪怕只是
new Form().Show()），否则无消息泵，钩子无法派发事件 - .NET Core/.NET 5+ 默认禁用 Win32 API 调用警告，需手动检查
SetWindowsHookEx返回值是否为 0 - 若用 WPF，推荐在
App.OnStartup中安装；WinForms 则在Program.Main启动窗体前调用
LowLevelKeyboardProc 回调里不能做哪些事
这个回调函数运行在系统级上下文，任何托管堆分配、跨线程同步、UI 更新、Console.WriteLine、Debug.Assert 都可能引发死锁或崩溃。它必须极快返回，且严禁阻塞。
常见错误现象：
- 按下键后整个桌面卡住 1–2 秒（因回调中调了
MessageBox.Show或Thread.Sleep） - WPF 应用抛出
InvalidOperationException：“调用线程无法访问此对象” - 日志写入失败但无异常（文件流未在回调中预创建/复用）
实操建议：
- 只做判断和转发：检查
wParam是WM_KEYDOWN还是WM_SYSKEYDOWN，读取KBDLLHOOKSTRUCT的vkCode和flags - 如需记录或响应，用
ThreadPool.UnsafeQueueUserWorkItem异步处理，或通过Control.Invoke/Dispatcher.BeginInvoke回 UI 线程 - 避免在回调内 new 对象；可复用静态
KBDLLHOOKSTRUCT实例（注意线程安全）
如何正确卸载全局键盘钩子并防止内存泄漏
钩子句柄不释放会导致系统资源持续占用，重启应用后旧钩子仍生效，甚至引发“重复拦截同一按键”现象。更隐蔽的问题是：.NET GC 不会自动清理非托管句柄，UnhookWindowsHookEx 必须显式调用，且只能调用一次。
实操建议：
- 把钩子句柄（
HHOOK）存为类字段，并在IDisposable.Dispose()中调用UnhookWindowsHookEx - WinForms 中监听
Form.FormClosing；WPF 中监听Application.Exit或窗体Closing事件 - 不要依赖终结器（
~ClassName()）——它可能在 UI 线程已销毁后才运行，导致UnhookWindowsHookEx失败 - 加一层防护：调用
UnhookWindowsHookEx前检查句柄是否为IntPtr.Zero，调用后立即设为IntPtr.Zero
为什么 Alt+Tab、Win 键、Ctrl+Esc 有时捕获不到
Windows 对部分系统热键做了隔离保护：WH_KEYBOARD_LL 能收到它们的 WM_KEYDOWN，但某些组合（如 Win+L、Alt+Tab）会在更低层被截断，回调中看到的 vkCode 可能是 0 或 VK_LWIN 却没有后续 WM_KEYUP；更关键的是，当系统处于锁定状态或 UAC 提权窗口激活时，钩子会被临时禁用。
实操建议：
- 不要依赖
vkCode == VK_TAB && (kbs.flags & LLKHF_ALTDOWN) != 0判断 Alt+Tab —— 它常不触发，或只触发一次 - 检测 Win 键可用
vkCode == VK_LWIN || vkCode == VK_RWIN，但需注意：Win+X、Win+R 等组合在目标进程获得焦点前就已被系统消费 - 若需拦截系统级快捷键，应改用注册热键（
RegisterHotKey），而非钩子；钩子更适合监控/辅助场景，而非强制接管
最易被忽略的一点：钩子回调函数的委托实例必须在整个生命周期内被 GC 保持引用，否则会被回收，导致后续按键完全无响应——务必用 static 字段或类成员长期持有该委托。
