我有一些关于 WH_MOUSE 的问题。根据我的阅读，通过将钩子放入 DLL 中，它会注入进程。这是否意味着捕获鼠标也可以在我的桌面、菜单启动等上工作？那么应用程序的标题栏呢？我在互联网上看到过一些有此类问题的帖子，但不知道它们是否因某些问题而失败或存在某种限制（或其他方法）。
我还有一个关于 WH_MOUSE 和 WH_MOUSE_LL 之间性能的问题。我在某处发现 WM_MOUSE 比 WH_MOUSE_LL 快，但它真的很明显吗？如果是这样，在什么情况下它会使系统减慢到我们可以注意到的程度？如果我只想记录鼠标和键盘的点击，WH_MOUSE_LL 会有效吗？
谢谢！
【问题讨论】：
标签： c++ performance winapi hook
这两个钩子都可以让您在屏幕上的任何位置进行鼠标输入（除了下面列出的情况），从高级功能的角度来看，它们本质上是相同的。
两者都受 UIPI 约束：当鼠标悬停在提升的进程上时，这两个钩子都不会让您获得鼠标输入。
低级挂钩不需要 DLL，因此可由 C# 使用。另一种类型需要使用非托管代码 (C/C++) 编写的单独 DLL。
如果在 64 位机器上运行，您可以同时运行 32 位和 64 位进程，低级挂钩将接收来自这两种类型的进程的事件，但另一种类型的的钩子只会看到来自与自身相同“位数”的进程的事件（此限制源于使用钩子 DLL；32 位钩子 DLL 只能钩入 32 位进程，同样适用于 64 位。 ) 因此，如果您关心这种情况，使用 LL 挂钩只需要一个进程，而使用另一种类型的挂钩则需要两个协作进程，一个用于 32，一个用于 64。
LL 挂钩需要运行消息循环。
LL 挂钩更容易编写，因为回调发生在您自己的进程中，因此您可以访问自己的全局变量等。使用另一种类型的钩子，回调发生在另一个进程中，因此您必须做额外的工作才能将信息传达回您的主进程。 （在这两种情况下，您都应该尽量减少回调中的代码；只需进行基本的过滤和检查，从您的主线代码中做任何重要的工作，而不是回调。）
LL 挂钩“较慢”，因为输入通知被编组到您的进程，在那里处理，然后上下文再次切换回原始进程。使用其他类型的钩子，没有上下文切换。然而，这可能会或可能不会被用户注意到，并且可能取决于您在回调中所做的事情、您如何处理信息、安装挂钩的时间以及其他因素。
标题栏的问题似乎已解决in this question；总结是您在标题栏（和其他非客户区域）上收到 WM_NCMOUSEMOVE 消息，在其他地方收到 WM_MOUSEMOVE，因此您必须检查 both。
我的 2c：如果您正在编写一个简单的实用程序或为了好玩而编写代码，请使用 _LL；它更容易为您处理大多数棘手的情况；您不必担心 64/32 位问题或进程之间的通信，因此您可以更快地启动和运行。当您的应用程序逻辑正常工作后，如果需要，您可以稍后将代码转换为其他类型的挂钩。另一方面，如果你想要一个更“专业”的应用程序，它是一个“好公民”，并将其对其他应用程序的影响降到最低，那么其他类型的钩子可能更合适；但与 perf 相关的所有事情一样，先测量，不要假设，所以即使那样，最好还是从 _LL 钩子开始。
【讨论】：