为何Windows API回调函数未执行？WM_CLOSE后SendAsyncProc不运行

嘿，这个问题我之前调试异步消息的时候也踩过类似的坑，咱们来梳理几个最可能的原因：

1. 目标进程退出太快，异步回调链路被打断 #

当你给egui.exe发送WM_CLOSE后，它很快完成终止、进程空间被系统回收了。而SendMessageAsync的回调触发逻辑是：系统要等目标窗口处理完消息，再通知发送方执行回调。但如果目标进程直接没了，系统会判定这个异步操作已经没有后续意义，直接跳过回调的执行——毕竟连接收消息的进程都不存在了，回调也就没必要跑了。

2. SendMessageAsync的调用前提没满足 #

要确保你调用SendMessageAsync时的几个关键条件是成立的：

• 传入的窗口句柄必须是egui.exe的有效主窗口句柄，不能是已经被标记销毁的无效句柄；
• 调用SendMessageAsync的线程必须保持存活且正常处理消息队列——如果你的发送线程在调用后直接退出，或者进入了没有消息循环的阻塞状态，回调根本没机会被触发。比如控制台程序如果不加消息循环，主线程跑完就退出，回调肯定不会执行。

3. egui.exe处理WM_CLOSE的方式特殊 #

有些程序收到WM_CLOSE时，不会走常规的窗口销毁流程（比如DestroyWindow→PostQuitMessage），而是直接调用ExitProcess或者被外部强制终止。这种情况下，系统还没来得及完成异步消息的回调通知流程，进程就没了，自然不会触发SendAsyncProc。

快速排查建议 #

• 先测试非终止类消息：把WM_CLOSE换成自定义消息（比如WM_USER + 100），看看回调是否正常触发，排除是WM_CLOSE导致进程退出的影响；
• 检查SendMessageAsync的返回值：如果返回FALSE，说明异步消息根本没排队成功，回调肯定不会跑；
• 确保发送线程保持消息循环：如果是控制台程序，可以在调用后加一段简单的消息循环代码，比如：

MSG msg;
while (GetMessage(&msg, NULL, 0, 0)) {
    TranslateMessage(&msg);
    DispatchMessage(&msg);
}

等回调触发后再退出循环。

内容的提问来源于stack exchange，提问作者Javad Bayat