SetWindowsHookEx无法直接监听其他进程窗口消息，因其仅支持线程或全局作用域，不按HWND过滤，且现代Windows限制非签名DLL注入及32/64位兼容性。
用 SetWindowsHookEx 监听其他进程窗口消息行不通
直接对非本进程窗口安装全局钩子（比如 WH_GETMESSAGE 或 WH_CALLWNDPROC）在现代 Windows（Vista+）上基本无效：系统会拒绝加载非签名的 DLL，且即使加载成功，64 位系统下 32/64 位进程间钩子也不兼容。更关键的是，SetWindowsHookEx 无法指定“只监听某个 HWND”，它作用于线程或全局，不是按窗口句柄过滤的机制。
真正可行的路径只有两条：一是让目标窗口所属进程主动配合（比如注入并改写其消息循环），二是从外部轮询或利用调试接口——但后者权限高、不稳定、易被杀软拦截。
最稳妥的做法：用 GetMessage + PeekMessage 配合 IsDialogMessage 模拟消息循环
如果你控制着目标窗口（比如它是你自己的子窗口、或你能在创建时指定其父窗口/消息处理逻辑），就别去“监听”——直接让它把消息转发给你。典型做法是：在目标窗口的 WndProc 中，对关心的消息（如 WM_KEYDOWN、WM_MOUSEMOVE）调用你预设的回调函数，或者发 PostMessage 到你的主线程窗口。
若目标窗口完全不可控（如第三方软件主窗口），唯一稳定方案是：用 SetWinEventHook 监听系统级事件（如焦点变化、控件状态更新），而非原始 Windows 消息。它不依赖钩子 DLL，运行在 COM 上下文中，兼容性好。
立即学习“C++免费学习笔记（深入）”；
-
EVENT_SYSTEM_FOREGROUND可捕获窗口获得焦点 -
EVENT_OBJECT_VALUECHANGE对应编辑框内容变化（需目标支持 UIA） - 必须用
UnhookWinEvent清理，否则句柄泄漏
为什么不用 SetTimer + GetForegroundWindow 轮询？
有人尝试用定时器每 50ms 调用 GetForegroundWindow 再比对 HWND，这看似简单，但漏消息严重：窗口可能在两次轮询之间完成整个消息生命周期（如快速点击按钮又释放），且无法获取具体消息参数（wParam/lParam）。更糟的是，GetForegroundWindow 返回的是前台窗口，不是“你关心的那个窗口”——它可能被遮挡、最小化、甚至无焦点。
真正需要精确消息内容时，轮询毫无意义。只有当业务只需“某窗口是否活跃”这类粗粒度状态时才可考虑，且应配合 GetWindowText 或 GetClassName 做二次确认，避免匹配到同名窗口。
调试级方案：DebugActiveProcess + WaitForDebugEvent 极其危险
理论上可通过调试 API 拦截目标进程的 DispatchMessage 调用，但这要求你以管理员权限运行、关闭 UAC 完整性检查、绕过 Windows Defender 的调试行为检测。实际中，99% 的商用软件会检测到调试器并退出，或直接崩溃。
除非你在做安全研究或逆向分析，且目标进程明确允许调试（如加了 DEBUG_PROCESS 标志启动），否则不要碰这条路。它不是“监听消息”的工程解法，而是破坏性探针。
真正容易被忽略的点是：所有跨进程消息观察都受限于 UIPI（用户界面特权隔离）。普通权限进程无法向更高完整性级别窗口发送或接收消息，连 SendMessageTimeout 都会返回 ERROR_ACCESS_DENIED —— 这个错误常被误判为窗口不存在，其实是权限卡死。
