1. 从窗口消息机制说起：为什么这两个API总被放在一起比较
做Windows桌面开发或者游戏辅助工具的朋友，大概率都绕不开两个函数：PostMessageA和SendMessageA。它们都来自user32.dll，都能往指定窗口投递消息，但行为差异极大。很多人第一次接触它们，是在做窗口自动化、模拟点击、或者游戏内交互的时候——比如想给某个游戏窗口发一个按键消息，让它执行某个动作。这时候问题就来了：用哪个？为什么有时候PostMessage发出去没反应，换成SendMessage就灵了？反过来也有场景是SendMessage直接把程序卡死，而PostMessage稳如老狗。
这个标题里还带了一个关键词——“游戏屏蔽”。这四个字才是真正的核心。游戏窗口对消息的处理和普通窗口完全不是一个量级。普通窗口可能老老实实走GetMessage→TranslateMessage→DispatchMessage的循环，你发什么它收什么。但游戏不一样，尤其是那些对输入敏感的游戏，它们会做各种校验：消息来源是不是真实的硬件输入？消息队列的时间戳对不对？鼠标坐标和窗口焦点状态匹配吗？甚至有些游戏会直接绕过消息队列，用Raw Input或者DirectInput来读键盘鼠标状态。这时候你再用PostMessage或SendMessage去发消息，大概率是石沉大海。
所以这篇文章要聊的，不只是这两个API的文档定义，而是它们在“游戏屏蔽”这个特殊场景下的实际表现差异、底层原理、以及我踩过的那些坑。如果你正在做窗口自动化、游戏内脚本、或者任何需要跨进程发送消息的事情，这些内容应该能帮你省下不少调试时间。
先给一个最直观的结论：PostMessage是“把信扔进对方邮箱就走”，SendMessage是“把信递给对方，站在门口等回复”。这个差异决定了它们在游戏场景下的命运完全不同。
2. PostMessageA与SendMessageA的底层行为差异
2.1 消息投递的同步与异步本质
PostMessageA的签名是BOOL PostMessageA(HWND hWnd, UINT Msg, WPARAM wParam, LPARAM lParam)。调用它之后，系统会把消息追加到目标窗口所属线程的消息队列末尾，然后函数立刻返回。目标线程什么时候处理这条消息，取决于它自己的消息循环什么时候轮到它。如果目标线程正在忙、消息队列积压、或者它根本不调用GetMessage/PeekMessage，这条消息就可能永远不被处理。
SendMessageA的签名是LRESULT SendMessageA(HWND hWnd, UINT Msg, WPARAM wParam, LPARAM lParam)。它不走消息队列，而是直接调用目标窗口的窗口过程（Window Procedure）。如果目标窗口和调用者在同一个线程，那就是一次普通的函数调用；如果跨线程，系统会挂起调用线程，直到目标线程处理完这条消息并返回结果。这意味着SendMessage是同步阻塞的，调用方必须等。
这个差异在普通窗口上可能只是性能问题，但在游戏场景下就是生死问题。游戏主线程通常跑着一个高帧率的渲染循环，它可能每帧只PeekMessage一次，甚至在某些全屏模式下完全不走标准消息循环。你PostMessage过去，消息进了队列，但游戏不取，等于没发。你SendMessage过去，系统强制目标线程处理，但如果目标线程正忙着渲染，你的调用线程就会被挂起，直到游戏那一帧结束。如果游戏卡了，你的程序也跟着卡。
2.2 跨进程消息传递的内核路径
从内核角度看，PostMessage最终会调用NtUserPostMessage，把消息写入目标线程的THREADINFO结构中的消息队列。这个过程涉及内核对象操作，但不需要目标线程参与。SendMessage则不同，跨进程时会调用NtUserSendMessage，内核会向目标线程插入一个特殊的“发送消息”结构，然后等待目标线程的KiUserCallbackDispatcher来处理。目标线程在处理完后，通过NtUserCallOneParam之类的机制唤醒调用线程。
这里有一个关键点：SendMessage在跨进程时，消息参数中的指针（比如lParam指向的字符串或结构体）不会被自动封送。如果你发的是WM_SETTEXT，系统会帮你处理字符串拷贝；但如果你发的是自定义消息，lParam里放了一个指向本进程内存的指针，目标进程拿到这个指针去访问，直接就是访问违规。PostMessage也有同样的问题，但因为它是异步的，指针可能在你释放内存之后才被使用，问题更隐蔽。
在游戏屏蔽的场景下，很多游戏会检查消息的lParam和wParam是否符合预期。比如鼠标消息，lParam的低16位是x坐标，高16位是y坐标。如果你用PostMessage发一个WM_LBUTTONDOWN，坐标是相对于窗口客户区的，但游戏可能期望的是屏幕坐标或者经过某种变换的坐标。SendMessage因为同步，你可以立刻知道返回值，但坐标问题依然存在。
2.3 消息队列与窗口过程的优先级
Windows的消息处理有一个优先级机制：SendMessage发送的消息（称为“非队列消息”）会优先于PostMessage发送的队列消息被处理。具体来说，当线程调用GetMessage或PeekMessage时，系统会先检查有没有待处理的SendMessage消息，有的话先处理它们，然后再从队列里取PostMessage消息。这个机制在普通应用里保证了同步调用的及时性，但在游戏里可能带来意外。
假设你同时用PostMessage发了一堆按键消息，又用SendMessage发了一个查询消息。游戏线程在处理时，会先处理SendMessage的查询，然后才处理队列里的按键。如果你依赖按键的顺序，这个优先级可能导致乱序。更麻烦的是，如果游戏在窗口过程里对某些消息做了特殊处理（比如直接return 0不往下传），你的SendMessage可能被吞掉，而PostMessage至少还在队列里。
我在一个模拟项目里遇到过这样的情况：给某个游戏窗口发WM_KEYDOWN，用PostMessage发VK_SPACE，游戏完全没反应。换成SendMessage，游戏角色跳了一下，但紧接着整个游戏卡了半秒。后来用调试器跟进去看，发现游戏的窗口过程在处理WM_KEYDOWN时，会调用一个内部函数去检查按键状态，这个函数会尝试获取一个锁，而这个锁正被渲染线程持有。SendMessage强制在游戏线程上下文执行，导致锁等待，渲染线程被拖慢。PostMessage虽然没反应，但至少没把游戏搞卡。
3. 游戏窗口为什么能“屏蔽”这些消息
3.1 消息来源校验：硬件输入与合成消息的区分
游戏屏蔽消息的第一道防线是检查消息来源。Windows在消息结构里有一个MSG结构，其中包含time和pt字段。对于真实的硬件输入，time是系统启动后的毫秒数，pt是屏幕坐标。而通过PostMessage或SendMessage发送的消息，这些字段要么是0，要么是调用者随便填的。游戏可以通过GetMessageTime和GetMessagePos来获取当前消息的时间戳和位置，然后和预期值对比。
更狠的是，有些游戏会调用GetAsyncKeyState或GetKeyState来直接查询物理按键状态。你发消息说“我按了空格”，但游戏一查，物理键盘的空格根本没按下，直接忽略。这种校验在竞技类游戏里非常常见，因为它们要防止自动化脚本。SendMessage和PostMessage都绕不过这个检查，因为消息本身不改变物理按键状态。
还有一个细节：PostMessage发送的消息，其MSG结构中的hwnd字段是目标窗口，但message字段是你指定的。游戏可以通过GetMessageExtraInfo获取额外的消息信息，这个信息在真实硬件输入时包含设备句柄等数据，而合成消息通常是0。有些游戏会检查这个值，非0才处理。
3.2 焦点与激活状态的前置条件
很多游戏窗口只在处于前台且拥有焦点时才会处理输入消息。如果你用PostMessage给一个后台窗口发WM_KEYDOWN，游戏可能直接忽略，因为它检查GetForegroundWindow是否等于自己。SendMessage也一样，消息虽然被处理了，但游戏在窗口过程里第一件事就是判断焦点状态，不满足就return。
这个机制在窗口化游戏里尤其明显。你切到别的窗口，游戏就暂停接收输入。有些游戏甚至会在失去焦点时清空消息队列，你之前PostMessage进去的消息全被丢弃。这时候你只能先把游戏窗口置顶并激活，再发消息。但激活窗口本身又可能触发游戏的其他逻辑，比如暂停菜单弹出，反而更麻烦。
我试过一个取巧的办法：用SetForegroundWindow把游戏窗口拉到前台，然后立刻PostMessage。但SetForegroundWindow有前台锁定限制，不是你想调就能调成功的。后来改用AttachThreadInput把当前线程的输入队列和游戏线程的绑定，再调用SetFocus，成功率会高一些。但这些都是治标不治本，游戏该屏蔽还是屏蔽。
3.3 原始输入与DirectInput的绕过机制
真正让PostMessage和SendMessage失效的，是游戏采用了Raw Input或DirectInput。这两种方式直接从驱动层读取输入设备的状态，完全不经过窗口消息队列。你往消息队列里塞再多WM_KEYDOWN，游戏根本不看。它只认GetRawInputData返回的数据或者DirectInput8设备的状态。
Raw Input的注册方式是RegisterRawInputDevices，游戏会指定接收WM_INPUT消息。但WM_INPUT消息里的数据是驱动填充的，你手动PostMessage一个WM_INPUT，里面的RAWINPUT结构你没法伪造，因为系统会校验数据来源。DirectInput更直接，它通过IDirectInputDevice8::GetDeviceState轮询设备状态，和消息队列完全无关。
在这种情况下，SendMessage和PostMessage的区别已经不重要了，因为游戏根本不走消息这条路。你只能考虑更底层的方案，比如驱动级模拟或者硬件模拟，但这些方案的门槛和风险都高得多。对于大多数窗口自动化需求，如果目标游戏用了Raw Input，基本可以放弃消息模拟这条路。
3.4 消息队列的完整性校验与反调试
有些游戏会定期检查自己的消息队列，看看有没有异常消息。比如，正常的消息队列里，消息的time字段应该是递增的，如果你PostMessage的消息时间戳是0或者乱填的，游戏可能检测到并触发反作弊逻辑。SendMessage因为不经过队列，反而不会留下这种痕迹，但它会在窗口过程里被检查调用栈。
更高级的反屏蔽手段是钩子（Hook）。游戏可以SetWindowsHookEx挂一个WH_GETMESSAGE钩子，在消息被GetMessage取出之前检查一遍。如果你的消息来自外部进程，钩子可以识别并丢弃。SendMessage的消息不经过GetMessage，但游戏可以在窗口过程里检查GetCurrentThreadId和GetWindowThreadProcessId，发现调用线程不是自己的线程，直接拒绝。
这些机制叠加起来，导致在游戏场景下，单纯靠PostMessage或SendMessage做自动化越来越难。这也是为什么很多老教程里的方法，放到新游戏上完全失效。
4. 实测对比：两种API在不同游戏场景下的表现
4.1 测试环境与方法的说明
为了把差异说清楚，我搭了一个简单的测试环境：一个MFC写的窗口程序模拟游戏窗口，它有一个消息循环，但故意加了各种校验逻辑。然后写一个控制台程序，分别用PostMessageA和SendMessageA发送WM_KEYDOWN、WM_LBUTTONDOWN、WM_MOUSEMOVE等消息，观察目标窗口的响应。
测试分三组：第一组是“宽松模式”，目标窗口不做任何校验，收到消息就记录；第二组是“焦点校验模式”，目标窗口只在拥有焦点时处理消息；第三组是“原始输入模式”，目标窗口忽略所有消息，只通过GetAsyncKeyState查询按键。每组测试都记录消息是否被处理、处理延迟、以及调用方的阻塞时间。
这个测试环境虽然简单，但基本覆盖了游戏屏蔽的几种典型情况。下面把结果整理成表格，方便对比。
| 测试组 | API | 消息是否被处理 | 调用方阻塞 | 备注 |
|---|---|---|---|---|
| 宽松模式 | PostMessageA | 是 | 无 | 消息进入队列，下一帧处理 |
| 宽松模式 | SendMessageA | 是 | 有，约0.1ms | 同步调用，立即处理 |
| 焦点校验 | PostMessageA | 否（无焦点时） | 无 | 消息被丢弃 |
| 焦点校验 | SendMessageA | 否（无焦点时） | 有，约0.1ms | 窗口过程直接返回 |
| 原始输入 | PostMessageA | 否 | 无 | 消息被忽略 |
| 原始输入 | SendMessageA | 否 | 有，约0.1ms | 窗口过程不处理 |
从表格可以看出，SendMessageA在任何情况下都会阻塞调用方，哪怕目标窗口不处理。而PostMessageA不阻塞，但消息可能永远不被处理。在焦点校验和原始输入模式下，两者都失效，区别只是SendMessage白白阻塞了一下。
4.2 鼠标消息的坐标陷阱
鼠标消息是游戏自动化里用得最多的，也是最容易出问题的。WM_LBUTTONDOWN的lParam里，低16位是x坐标，高16位是y坐标，相对于窗口客户区。WM_MOUSEMOVE也一样。但游戏在接收这些消息时，可能会做坐标变换：比如把客户区坐标转换成世界坐标，或者检查坐标是否在某个UI区域内。
用PostMessage发鼠标消息时，如果坐标不对，游戏可能直接忽略。更麻烦的是，有些游戏会检查鼠标消息是否伴随着WM_SETCURSOR或WM_MOUSEFIRST之类的消息。你单独发一个WM_LBUTTONDOWN，游戏可能认为这不是一个完整的点击序列，因为缺少WM_LBUTTONUP或者WM_MOUSEMOVE的前置。
SendMessage发鼠标消息时，因为同步，你可以立刻知道游戏有没有处理。但坐标问题依然存在。我试过一个方法：先用GetClientRect和ClientToScreen算出窗口在屏幕上的位置，然后根据目标控件的相对坐标反推出客户区坐标。但游戏窗口可能有缩放、有黑边、有DPI缩放，算出来的坐标经常偏几个像素，导致点击落空。
还有一个坑：PostMessage发送的鼠标消息，其pt字段（在MSG结构里）是0,0，而真实鼠标消息的pt是屏幕坐标。游戏如果检查GetMessagePos，就会发现异常。SendMessage不经过消息队列，GetMessagePos返回的是上一条真实消息的位置，可能更离谱。
4.3 键盘消息的扫描码与虚拟键码
键盘消息比鼠标消息更复杂。WM_KEYDOWN的wParam是虚拟键码（VK），lParam包含扫描码、扩展键标志、重复计数等信息。游戏在判断按键时，可能同时检查虚拟键码和扫描码。你PostMessage一个VK_SPACE，但lParam里的扫描码是0，游戏可能认为这不是一个有效的按键。
真实的键盘消息，lParam的位0-15是扫描码，位16-23是扩展键标志，位24是Alt键状态，位29是上下文代码，位30是前一个键状态，位31是转换状态。这些位都有含义，游戏可能检查其中几个。你手动构造lParam，很难做到和真实消息完全一致。
SendMessage发键盘消息时，同样面临lParam的问题。而且因为同步，如果游戏在窗口过程里对WM_KEYDOWN做了耗时操作（比如触发一个复杂的技能计算），你的调用线程会被卡住。我遇到过发一个SendMessage过去，游戏卡了200毫秒才返回，因为那一帧正好在加载资源。
4.4 消息发送频率与游戏帧率的匹配
游戏通常以固定帧率运行，比如60帧每秒，每帧约16.6毫秒。如果你用PostMessage以很高的频率发送消息，消息会在队列里堆积，游戏每帧可能只处理一条或几条，导致实际响应频率远低于发送频率。如果你用SendMessage，每次调用都会强制游戏线程处理，如果发送频率超过游戏帧率，游戏线程会被消息处理占满，渲染帧率下降。
我做过一个测试：用PostMessage每秒发1000个WM_MOUSEMOVE，游戏的消息队列迅速积压，内存占用上升，游戏帧率从60降到20。换成SendMessage，每秒发1000个，游戏直接卡成幻灯片，因为每次调用都要等游戏线程处理完。后来把频率降到每秒60个，和游戏帧率匹配，PostMessage的表现明显好于SendMessage，因为消息不会阻塞调用方，游戏也能在每帧处理一条。
这个经验说明：在游戏场景下，PostMessage更适合高频、非关键的消息，比如鼠标移动；SendMessage适合低频、需要立即知道结果的消息，比如查询某个状态。但前提是游戏没有屏蔽这些消息。
5. 绕过屏蔽的常见思路与各自的局限
5.1 消息伪装：构造更真实的MSG结构
既然游戏会检查消息来源，那能不能把消息伪装得更真实？思路是：不直接调用PostMessage，而是用SetWindowsHookEx挂一个WH_GETMESSAGE钩子，在钩子过程里修改消息的time、pt等字段，让它看起来像真实输入。或者用keybd_event、mouse_event这类API，它们会生成更接近硬件的消息。
keybd_event和mouse_event已经被标记为过时，推荐用SendInput。SendInput会把输入插入到系统输入流中，经过驱动层，生成的消息和真实硬件输入几乎一样。游戏的消息队列会收到这些消息，GetAsyncKeyState也能查到按键状态。但SendInput需要窗口有焦点，而且它会影响整个系统的输入状态，如果你在自动化的时候用户还在用电脑，会互相干扰。
还有一个问题是，SendInput生成的输入，其MSG结构里的hwnd是前台窗口，如果你的目标游戏不是前台窗口，消息会发到别的窗口去。所以用SendInput必须先把游戏窗口激活。而激活窗口本身又可能触发游戏的反作弊检测，因为正常的玩家不会频繁地程序化激活窗口。
5.2 线程输入队列附加与焦点欺骗
AttachThreadInput是一个老技巧：把当前线程的输入队列附加到目标线程，这样两个线程共享输入状态。附加之后，你可以调用SetFocus把焦点设置到目标窗口，即使它不在前台。这样PostMessage发送的键盘消息，游戏在检查焦点时可能会通过。
但这个技巧有几个限制。第一，AttachThreadInput要求两个线程在同一个桌面会话，跨会话不行。第二，附加之后，输入队列的同步会带来性能开销，而且如果目标线程崩溃，你的线程也可能受影响。第三，现代游戏可能不检查GetFocus，而是检查GetForegroundWindow，附加线程并不能改变前台窗口。
我试过在一个模拟项目里用AttachThreadInput，成功让后台窗口接收到了键盘消息，但游戏的角色移动方向完全乱了，因为游戏同时还在读GetAsyncKeyState，而物理按键并没有按下，导致逻辑冲突。后来只能放弃这个方案。
5.3 驱动级模拟与硬件模拟的可行性
如果消息层完全被屏蔽，剩下的路就是驱动级模拟。比如写一个虚拟键盘驱动，让系统认为有一个真实的键盘设备。这种方案技术上可行，但门槛极高：需要签名驱动、需要处理即插即用、需要兼容各种游戏的反作弊。而且很多游戏的反作弊会检测虚拟设备，一旦发现就封号。
硬件模拟是另一个方向：用Arduino或者树莓派做一个USB HID设备，模拟键盘鼠标。这种方案从硬件层面看就是真实设备，游戏很难区分。但缺点是需要额外的硬件，而且部署起来不灵活。对于批量自动化的场景，成本太高。
对于大多数普通开发者来说，驱动级和硬件级方案都不现实。所以现实的做法是：先判断目标游戏用的是哪种输入方式，如果是标准消息循环，优先用PostMessage；如果用了Raw Input，考虑SendInput；如果连SendInput都被屏蔽，那基本只能放弃消息模拟这条路。
5.4 反屏蔽与反反屏蔽的持续对抗
游戏屏蔽消息的手段在进化，绕过的手段也在进化。这是一个持续的对抗过程。早期游戏只检查消息来源，后来检查焦点，再后来用Raw Input，现在很多游戏还会做行为分析：比如检测鼠标移动的轨迹是否过于平滑、按键间隔是否过于规律。这些分析在服务器端做，你本地怎么模拟都没用。
我在一个模拟项目里遇到过这样的情况：本地测试一切正常，消息发过去游戏有反应，但一连接到服务器，操作就被判定为异常。后来分析发现，服务器会记录每个操作的精确时间戳，如果两个操作之间的间隔小于人类反应极限（比如50毫秒），就判定为脚本。这种检测在客户端是看不到的，只有服务器知道。
所以，讨论PostMessage和SendMessage的差异，只是在客户端消息层面的对抗。真正要稳定地做游戏自动化，需要考虑的远不止这两个API。但对于理解消息机制、排查为什么消息没反应，这些知识是基础。
6. 从调试器里看到的真实调用链路
6.1 用API Monitor观察消息流向
要搞清楚PostMessage和SendMessage到底做了什么，最直接的办法是用API监控工具。我习惯用一款轻量的API Monitor，挂上user32.dll的PostMessageA、SendMessageA、GetMessageA、PeekMessageA、DispatchMessageA这几个函数，然后运行目标程序，看调用顺序。
在宽松模式下，用PostMessageA发一个WM_KEYDOWN，API Monitor里会看到：调用PostMessageA→返回TRUE→目标线程调用PeekMessageA→取出消息→调用DispatchMessageA→进入窗口过程。整个过程是异步的，PostMessageA返回时，消息还没被处理。
用SendMessageA发同样的消息，API Monitor里会看到：调用SendMessageA→目标线程直接进入窗口过程（没有PeekMessageA和DispatchMessageA）→窗口过程返回→SendMessageA返回。整个过程是同步的，调用线程在SendMessageA处等待。
这个观察结果和文档描述一致，但在实际调试时，能看到更多细节。比如，SendMessageA在跨进程时，API Monitor会显示一个额外的NtUserSendMessage调用，而PostMessageA显示的是NtUserPostMessage。这些内核调用揭示了消息传递的底层路径。
6.2 窗口过程里的消息过滤逻辑
在目标程序的窗口过程里下断点，可以看到游戏是怎么过滤消息的。我模拟的游戏窗口，窗口过程开头有这么一段逻辑：
if (msg == WM_KEYDOWN || msg == WM_KEYUP) { if (GetForegroundWindow() != hWnd) { return 0; // 不是前台窗口，忽略 } if (GetAsyncKeyState(wParam) == 0) { return 0; // 物理按键没按下，忽略 } }这段逻辑直接解释了为什么PostMessage和SendMessage在焦点校验和原始输入模式下都失效。GetForegroundWindow检查的是前台窗口，GetAsyncKeyState检查的是物理按键状态。这两个检查都不是消息本身能绕过的。
更复杂的游戏还会检查消息的time字段：
if (msg == WM_KEYDOWN) { DWORD msgTime = GetMessageTime(); DWORD now = GetTickCount(); if (now - msgTime > 100) { return 0; // 消息太旧，忽略 } }GetMessageTime返回的是当前消息的时间戳。对于PostMessage发送的消息，这个时间戳是调用PostMessage时系统填的，通常和GetTickCount接近。但如果你在消息队列里积压了很久，时间戳就会变旧。SendMessage不经过队列，GetMessageTime返回的是上一条队列消息的时间，可能更离谱。
6.3 消息钩子的拦截点与绕过可能
游戏可以用SetWindowsHookEx挂WH_GETMESSAGE钩子，在消息被GetMessage取出之前拦截。钩子过程可以检查消息的hwnd、message、wParam、lParam，如果发现是外部进程发来的，直接修改消息内容或者丢弃。
要绕过这种钩子，一个思路是直接调用窗口过程，跳过消息队列。但窗口过程的地址不是公开的，你需要用GetWindowLongPtr获取GWLP_WNDPROC，然后直接调用。但这样调用会绕过系统的消息过滤，而且如果窗口过程内部依赖消息队列的状态（比如GetMessageTime），可能会出错。
另一个思路是用SendMessage，因为SendMessage不经过GetMessage，钩子拦不到。但游戏可以在窗口过程里检查调用线程，发现不是自己的线程就拒绝。所以SendMessage也不是万能的。
我在调试一个模拟项目时，发现游戏在窗口过程里加了这样的检查：
if (GetCurrentThreadId() != g_dwGameThreadId) { // 不是游戏主线程，可能是外部调用 if (msg == WM_KEYDOWN) { return 0; } }这个检查直接封死了SendMessage的路，因为SendMessage跨进程时，窗口过程是在目标线程上下文执行的，GetCurrentThreadId返回的是目标线程ID，按理说应该等于g_dwGameThreadId。但游戏可能通过其他方式判断，比如检查调用栈里的返回地址是否在自己的模块范围内。这种检查很难绕过，因为调用栈是真实的。
6.4 从调用栈判断消息来源的可行性
调用栈检查是反屏蔽的高级手段。游戏在窗口过程里调用RtlCaptureStackBackTrace或者手动遍历栈帧，看看调用DispatchMessage的地址是不是在自己的代码段里。如果是外部进程通过SendMessage调用的，调用栈里会出现user32.dll的KiUserCallbackDispatcher，这个地址不在游戏模块内，很容易被识别。
要绕过调用栈检查，理论上可以用CreateRemoteThread在目标进程里注入代码，然后从目标进程内部调用SendMessage或直接调用窗口过程。这样调用栈看起来就是目标进程自己的。但注入代码本身会被反作弊检测，而且需要处理进程权限、内存分配等问题，复杂度很高。
对于普通开发者，我的建议是：不要试图绕过调用栈检查。如果游戏已经做到了这一步，说明它的反作弊级别很高，继续对抗的成本和风险都太大。不如换个思路，比如用图像识别或者内存读取，虽然也有风险，但至少不在消息层面硬碰硬。
7. 实际项目中的选型建议与避坑清单
7.1 什么情况下优先用PostMessageA
PostMessageA的优势是异步、不阻塞、对调用方友好。在以下场景优先考虑：
- 目标窗口是标准Windows窗口，消息循环正常，没有做严格的消息来源校验。
- 需要高频发送消息，比如鼠标移动轨迹模拟，用
PostMessage不会拖慢调用方。 - 调用方和目标窗口在同一个进程，或者跨进程但目标窗口不检查调用线程。
- 消息本身不要求立即返回结果，比如
WM_CLOSE、WM_MOUSEMOVE。
但要注意，PostMessage的消息可能丢失。如果目标线程的消息队列满了（默认上限是10000条），PostMessage会失败并返回FALSE。在高频发送时，要检查返回值，必要时降低频率或增加延迟。
还有一个坑：PostMessage发送的WM_QUIT消息，如果目标窗口不处理，会导致线程退出。这在自动化里要特别小心，别不小心把游戏关了。
7.2 什么情况下必须用SendMessageA
SendMessageA的优势是同步、能拿到返回值、消息不会被队列积压。在以下场景必须用：
- 需要立即知道消息处理结果，比如查询窗口文本、获取控件状态。
- 目标窗口的消息队列可能被阻塞，
PostMessage进去的消息长时间不被处理。 - 需要发送
WM_COPYDATA之类的跨进程数据传递消息，SendMessage是标准做法。 - 目标窗口在另一个线程，但你需要确保消息被处理后再继续。
但SendMessage的阻塞特性是双刃剑。如果目标线程死锁或者忙，你的调用线程会一直等。在UI线程里调用SendMessage要特别小心，可能导致界面无响应。一个常见的做法是设置超时：用SendMessageTimeout代替SendMessage，指定超时时间，避免无限等待。
SendMessageTimeout的签名是LRESULT SendMessageTimeoutA(HWND hWnd, UINT Msg, WPARAM wParam, LPARAM lParam, UINT fuFlags, UINT uTimeout, PDWORD_PTR lpdwResult)。fuFlags可以设SMTO_ABORTIFHUNG，如果目标线程挂起就立即返回；uTimeout设一个合理的毫秒数，比如1000。这样即使目标线程有问题，你的程序也不会卡死。
7.3 消息发送失败时的排查顺序
当你发现消息发出去没反应，按以下顺序排查：
- 确认窗口句柄有效：用
IsWindow检查hWnd是否有效。窗口可能已经销毁，但你手里的句柄还是旧的。 - 确认消息类型正确：
WM_KEYDOWN的wParam是虚拟键码，WM_CHAR的wParam是字符码。别搞混了。 - 检查焦点和前台状态：用
GetForegroundWindow和GetFocus看看目标窗口是否满足游戏的前置条件。 - 检查物理按键状态：用
GetAsyncKeyState看看游戏期望的物理按键是否按下。如果游戏检查这个，消息模拟基本无效。 - 用API Monitor观察消息流向：确认
PostMessage或SendMessage是否被调用，返回值是什么，目标线程是否处理了消息。 - 检查消息队列是否积压：用
GetQueueStatus查看目标线程的消息队列状态。如果QS_KEY、QS_MOUSE等标志一直有值，说明消息没被处理。 - 尝试
SendInput：如果消息模拟完全无效，试试SendInput，它生成的消息更接近真实输入。 - 考虑放弃消息模拟：如果以上都无效，目标游戏可能用了
Raw Input或驱动级输入，消息模拟这条路走不通。
这个排查顺序是我在实际项目中总结的，能覆盖大部分情况。每一步都有对应的API和工具，不要跳步，按顺序来。
7.4 跨进程消息传递的内存安全注意事项
跨进程发送消息时，wParam和lParam里的指针是最大的坑。PostMessage和SendMessage都不会自动封送指针，目标进程拿到的是你进程的虚拟地址，直接访问就是访问违规。
对于系统定义的消息，比如WM_SETTEXT、WM_GETTEXT、WM_COPYDATA，系统会帮你处理数据拷贝。但自定义消息，你必须自己处理。常用的做法是：
- 用
WM_COPYDATA传递数据，系统会帮你拷贝到目标进程的地址空间。 - 用共享内存（
CreateFileMapping）传递大数据，消息里只传共享内存的句柄或名称。 - 用
SendMessage发送消息，然后在目标进程里用ReadProcessMemory读取调用进程的数据。但这需要目标进程有相应的权限和代码。
在游戏场景下，自定义消息很少用，因为游戏通常不处理外部消息。但如果你在做窗口间通信，这些注意事项很重要。我见过有人用PostMessage发了一个指向栈上字符串的指针，目标进程处理消息时，调用线程早就返回了，栈内存被回收，目标进程读到的是垃圾数据，直接崩溃。
7.5 我踩过的三个典型坑与修复过程
第一个坑：用PostMessage发WM_LBUTTONDOWN和WM_LBUTTONUP，游戏没反应。排查后发现，游戏在窗口过程里检查GetMessagePos，要求鼠标位置在窗口内。PostMessage的pt字段是0,0，不满足条件。修复方法：改用SendInput，先把鼠标移动到目标位置，再模拟点击。
第二个坑：用SendMessage发WM_KEYDOWN，游戏卡死。排查后发现，游戏在窗口过程里对WM_KEYDOWN做了耗时操作，而SendMessage是同步的，调用线程被阻塞。修复方法：改用PostMessage，虽然游戏可能不处理，但至少不会卡死调用方。后来发现游戏确实不处理PostMessage的键盘消息，最终放弃了消息模拟。
第三个坑：用AttachThreadInput附加线程后，PostMessage的键盘消息被游戏处理了，但游戏角色移动异常。排查后发现，游戏同时读GetAsyncKeyState，物理按键没按下，导致逻辑冲突。修复方法：无解，只能放弃这个方案。
这三个坑的共同点是：消息模拟在游戏场景下非常脆弱，任何一个校验点都可能让整个方案失效。所以在做技术选型时，先花时间确认目标游戏的输入方式，再决定用哪种方案。不要一上来就写代码，否则调试的时间远超预期。
8. 消息机制之外：什么时候该换赛道
聊了这么多PostMessage和SendMessage的细节，最后说点实在的。如果你发现目标游戏对消息的屏蔽非常严格，PostMessage、SendMessage、SendInput都无效，那继续在消息层面折腾意义不大。这时候可以考虑换赛道：
- 图像识别：用屏幕截图加模板匹配或OCR，找到目标位置，然后用
SendInput点击。这种方案不依赖消息，但受分辨率和画面变化影响。 - 内存读取：直接读游戏进程的内存，获取角色坐标、状态等信息。这种方案需要处理进程权限和反作弊，风险较高。
- 网络协议分析：如果游戏是网络游戏，分析它的通信协议，直接构造数据包。这种方案需要抓包和逆向，门槛最高，但一旦成功最稳定。
这些方案各有优劣，但都不是消息机制能覆盖的。PostMessage和SendMessage只是Windows消息体系里的两个函数，它们能做的事情有限。理解它们的差异和局限，是为了在合适的场景用合适的工具，而不是把它们当成万能钥匙。
我在实际项目里的体会是：先花半天时间用API Monitor和调试器确认游戏的输入方式，再决定技术方案。如果游戏走标准消息循环，PostMessage和SendMessage能解决大部分问题；如果游戏用了Raw Input，直接考虑SendInput；如果连SendInput都被屏蔽，那就得评估是否值得继续投入。很多时候，换一个目标或者换一种交互方式，比硬刚反作弊机制更划算。
