简介：这份VC/MFC源代码资源聚焦Windows系统下的鼠标消息模拟，面向具备一定C++基础、希望理解鼠标单击与双击底层响应机制的开发者。工程在窗体上布置若干按钮，通过点击按钮触发对鼠标单击、双击行为的模拟，帮助读者直观观察消息产生、传递与系统配合的完整过程，适合作为MFC消息机制与输入模拟的入门练习。压缩包共21个文件，约29KB，以h头文件与cpp源文件为主体，另有ico图标、bmp位图、rc资源脚本及dsp、dsw工程文件，构成可直接编译运行的完整VC工程。目前已有689人学习。读者可从中获得一套结构清晰的MFC示例工程，借助视图类、文档类与主框架类的分工理解鼠标事件处理流程，并在此基础上扩展自定义点击逻辑或调试输入响应问题。
1. 鼠标模拟这件事，难点从来不在“点一下”
“VC++模拟鼠标单击、双击的实现”这个标题，看起来像是入门级的 Win32 调用练习，但真正落到项目里，翻车点往往不在mouse_event或SendInput本身，而在于目标窗口收不到、双击被识别成两次单击、坐标被 DPI 缩放悄悄改掉。我做过一个自动化测试辅助工具，需求很朴素：在指定窗口的固定位置完成单击和双击，结果前三天全耗在“为什么消息发出去了但界面没反应”上。这篇文章面向两类人：一是需要在 VC++ 里做 UI 自动化、辅助操作、批量点击的开发者；二是已经会调 API，但被焦点、坐标、时序问题卡住的熟手。下面按“先选对 API，再写对代码，最后避开坑”的顺序讲透。
2. 选 SendInput 还是 mouse_event：先定 API 再谈实现
2.1 两代鼠标模拟 API 的差异与选型理由
Windows 上模拟鼠标输入，主流就两条路：老牌的mouse_event和从 XP 之后推荐的SendInput。mouse_event是早期 API，内部最终也会走到输入队列，但它在多显示器、高 DPI、UAC 提权场景下的行为不够可控，微软官方文档已经把它标记为被SendInput取代。SendInput的优势在于：它把键盘、鼠标、硬件事件统一成INPUT结构体数组，可以一次性提交一串事件，系统按顺序注入，时序更接近真实硬件。
选型上我的建议很直接：新项目一律用SendInput。只有在维护十几年前的老代码、且目标环境确定是低版本系统时，才考虑mouse_event。原因不是mouse_event不能用，而是它的坐标处理和事件合并行为在不同系统版本上有细微差别，排查成本高。SendInput的另一个好处是返回值明确——它返回成功注入的事件数量，如果返回 0，说明被 UIPI（用户界面特权隔离）拦了，这比mouse_event无声无息地失败要好排查得多。
还有一个容易被忽略的点：SendInput注入的事件会进入系统输入流，和真实鼠标事件走同一条路，所以目标程序如果用了低级钩子（WH_MOUSE_LL），是能感知到的。这一点在合规的自动化场景里是好事，在需要“隐身”的场景里则是限制。做技术方案时要把这个边界想清楚。
2.2 单击的最小可运行实现
先给一个能直接编译运行的单击函数。用 Visual Studio 建一个 Win32 控制台或窗口工程都行，包含<windows.h>即可。
#include <windows.h> // 在屏幕坐标 (x, y) 处模拟一次左键单击 // x, y 使用绝对屏幕坐标（像素） bool SimulateLeftClick(int x, int y) { // 把屏幕坐标归一化到 0~65535，SendInput 的绝对坐标要求 int screenW = GetSystemMetrics(SM_CXSCREEN); int screenH = GetSystemMetrics(SM_CYSCREEN); INPUT inputs[2] = {}; // 第一次：移动鼠标到目标位置 inputs[0].type = INPUT_MOUSE; inputs[0].mi.dx = (LONG)(x * 65535.0 / (screenW - 1) + 0.5); inputs[0].mi.dy = (LONG)(y * 65535.0 / (screenH - 1) + 0.5); inputs[0].mi.dwFlags = MOUSEEVENTF_MOVE | MOUSEEVENTF_ABSOLUTE; // 第二次：按下并抬起左键 inputs[1].type = INPUT_MOUSE; inputs[1].mi.dwFlags = MOUSEEVENTF_LEFTDOWN | MOUSEEVENTF_LEFTUP; UINT sent = SendInput(2, inputs, sizeof(INPUT)); return sent == 2; }逻辑说明：SendInput的绝对坐标不是像素，而是把屏幕宽高映射到 0 到 65535 的归一化值，所以必须先GetSystemMetrics拿到当前主屏分辨率再换算。MOUSEEVENTF_ABSOLUTE告诉系统这是绝对坐标，不加这个标志dx/dy会被当成相对位移。按下和抬起放在同一个INPUT里用|组合，系统会在一次注入中完成，避免中间被其他事件插入。
参数说明：x、y是屏幕像素坐标，原点在左上角。screenW - 1而不是screenW，是因为归一化区间是闭区间，用screenW会在最右边缘产生一像素偏差。+ 0.5是四舍五入，避免整数截断导致点击位置偏左偏上。返回值判断sent == 2，如果只返回 1 或 0，说明部分或全部事件被拦截，需要检查目标进程权限。
2.3 双击为什么不能简单调两次单击
很多人第一版双击就是循环调用两次上面的单击函数，结果目标程序要么没反应，要么识别成两次独立单击。原因是 Windows 判断双击靠的是GetDoubleClickTime()返回的时间窗口（默认 500 毫秒）和两次点击之间的位移容差。如果两次SendInput之间隔得太久，或者中间鼠标位置有微小偏移，系统就不认为是双击。
正确做法有两种。第一种是手动控制时序，两次点击间隔压到 100 到 200 毫秒，并且第二次点击前不移动鼠标。第二种是直接用MOUSEEVENTF_LEFTDOWN | MOUSEEVENTF_LEFTUP连续注入两次，中间不加MOUSEEVENTF_MOVE。我一般用第一种，因为间隔可控，方便调试。
// 在 (x, y) 处模拟双击，intervalMs 为两次点击间隔 bool SimulateDoubleClick(int x, int y, int intervalMs = 120) { if (!SimulateLeftClick(x, y)) return false; Sleep(intervalMs); // 第二次点击不再移动鼠标，直接按下抬起 INPUT inputs[1] = {}; inputs[0].type = INPUT_MOUSE; inputs[0].mi.dwFlags = MOUSEEVENTF_LEFTDOWN | MOUSEEVENTF_LEFTUP; UINT sent = SendInput(1, inputs, sizeof(INPUT)); return sent == 1; }逻辑说明：第一次点击负责把鼠标移到目标位置并完成按下抬起，第二次只发按下抬起，不再带MOUSEEVENTF_MOVE，这样鼠标位置不变，满足双击的位移容差要求。intervalMs默认 120 毫秒，远小于系统默认的 500 毫秒窗口，同时又不至于快到被某些程序的消息队列合并。
参数说明：intervalMs不要低于 50 毫秒，部分程序的消息循环处理不过来会丢事件；也不要高于GetDoubleClickTime()的返回值，否则系统不认。稳妥区间是 80 到 200 毫秒。如果目标程序自己实现了双击判定逻辑，需要按它的规则调整，这时候就得看它的文档或反汇编了。
3. 让目标窗口真正收到点击：焦点、坐标与消息循环
3.1 前台焦点与 SetForegroundWindow 的权限限制
SendInput注入的是全局输入事件，它会发给当前前台窗口。如果你的目标窗口不在前台，点击就落到了别的窗口上。所以模拟点击前通常要先激活目标窗口。常见做法是SetForegroundWindow，但这个函数有权限限制：只有当前进程是前台进程，或者满足一系列条件（比如由用户操作触发）时才能成功。
我踩过的坑是：在后台服务或计划任务里调SetForegroundWindow，返回成功但窗口没激活。解决办法是先用ShowWindow(hwnd, SW_RESTORE)把最小化的窗口还原，再调SetForegroundWindow，如果还不行，用AttachThreadInput把当前线程的输入队列附加到目标窗口线程，激活后再分离。这套组合拳能覆盖绝大多数场景，但要注意附加输入队列有副作用，操作完必须AttachThreadInput(FALSE)分离，否则两个线程的输入状态会互相干扰。
// 尝试把 hwnd 激活到前台 bool ForceForeground(HWND hwnd) { if (IsIconic(hwnd)) ShowWindow(hwnd, SW_RESTORE); DWORD foreThread = GetWindowThreadProcessId(GetForegroundWindow(), NULL); DWORD curThread = GetCurrentThreadId(); if (foreThread != curThread) { AttachThreadInput(foreThread, curThread, TRUE); SetForegroundWindow(hwnd); AttachThreadInput(foreThread, curThread, FALSE); } else { SetForegroundWindow(hwnd); } return GetForegroundWindow() == hwnd; }逻辑说明：先还原最小化窗口，再判断前台窗口线程和当前线程是否一致。不一致时附加输入队列，让当前线程临时获得设置前台窗口的权限，设置完立即分离。返回值用GetForegroundWindow() == hwnd实际校验，而不是只看SetForegroundWindow的返回值，因为它的返回值不可靠。
参数说明：AttachThreadInput的第三个参数TRUE表示附加，FALSE表示分离，必须成对出现。GetWindowThreadProcessId第一个参数传NULL时只返回线程 ID，不关心进程 ID。这套逻辑在目标窗口属于其他进程、且当前进程权限不低于目标进程时有效；如果目标进程以管理员权限运行，当前进程也必须提权，否则 UIPI 会拦截。
3.2 客户区坐标与屏幕坐标的换算
另一个高频翻车点是坐标系搞混。SendInput用的是屏幕坐标，而很多 UI 自动化库或控件 API 用的是客户区坐标。如果你从控件拿到的坐标直接丢给SendInput，点击位置会整体偏移，偏移量就是窗口客户区左上角在屏幕上的位置。
换算方法是ClientToScreen。假设你有一个子窗口或控件的客户区坐标(cx, cy)，先转成屏幕坐标再调SimulateLeftClick。
// 把 hwnd 客户区坐标 (cx, cy) 转成屏幕坐标后单击 bool ClickClientPoint(HWND hwnd, int cx, int cy) { POINT pt = { cx, cy }; if (!ClientToScreen(hwnd, &pt)) return false; return SimulateLeftClick(pt.x, pt.y); }逻辑说明：ClientToScreen把相对于hwnd客户区左上角的坐标转换成屏幕绝对坐标，pt既是输入也是输出。转换后再走前面的单击逻辑，坐标就对齐了。
参数说明：cx、cy是相对于客户区左上角的像素坐标，不是相对于窗口边框。如果拿到的是窗口坐标（含标题栏和边框），要先用ScreenToClient或手动减去边框宽度。多显示器环境下，ClientToScreen返回的坐标可能是负值（副屏在主屏左侧时），SendInput的归一化公式要按虚拟屏幕范围算，不能只用主屏分辨率，这是多屏场景的隐藏坑。
3.3 用 PostMessage 直接发消息的适用边界
有些场景下不方便抢焦点，比如目标窗口在后台运行、用户还在用电脑做别的事。这时候可以用PostMessage直接往目标窗口发WM_LBUTTONDOWN、WM_LBUTTONUP、WM_LBUTTONDBLCLK消息。好处是不影响前台焦点，坏处是很多程序不处理这些消息，或者处理逻辑和真实输入不一致。
// 直接向 hwnd 发送单击消息（不移动真实鼠标） void PostClickMessage(HWND hwnd, int cx, int cy) { LPARAM lParam = MAKELPARAM(cx, cy); PostMessage(hwnd, WM_LBUTTONDOWN, MK_LBUTTON, lParam); PostMessage(hwnd, WM_LBUTTONUP, 0, lParam); }逻辑说明：lParam的低 16 位是 x 坐标，高 16 位是 y 坐标，用MAKELPARAM拼装。wParam在按下时传MK_LBUTTON，抬起时传 0。双击则把第二次的WM_LBUTTONDOWN换成WM_LBUTTONDBLCLK。
参数说明：cx、cy是客户区坐标。这种方式只对用标准消息循环处理鼠标的程序有效，对 DirectX、游戏引擎、自绘控件基本无效，因为它们读的是原始输入或GetCursorPos。判断标准很简单：如果目标程序在真实鼠标点击时能响应，但PostMessage没反应，就说明它不依赖消息，得回到SendInput。
4. 避坑与排查：五个真实踩过的坑
4.1 坑一：点击发出去了，目标窗口毫无反应
现象：SendInput返回 2，代码没报错，但目标按钮没被按下。
原因：目标窗口不在前台，或者当前进程权限低于目标进程，被 UIPI 拦截。UIPI 会静默丢弃低权限进程发往高权限窗口的输入事件，SendInput的返回值在这种情况下可能仍然正常。
解决：先用ForceForeground激活目标窗口，确认GetForegroundWindow()返回的是目标句柄。如果目标进程以管理员权限运行，把当前程序也设为以管理员权限运行，或者用ChangeWindowMessageFilterEx放行相关消息（仅对PostMessage路线有效）。排查时可以在点击前后各调一次GetCursorPos，看鼠标是否真的移动了。
4.2 坑二：双击被识别成两次单击
现象：目标程序执行了两次单击对应的操作，而不是一次双击操作。
原因：两次点击间隔超过了GetDoubleClickTime()，或者第二次点击前鼠标位置变了，超出双击的位移容差。
解决：把intervalMs压到 200 毫秒以内，第二次点击不带MOUSEEVENTF_MOVE。如果目标程序自己维护双击状态，检查它的判定逻辑。可以用GetDoubleClickTime()读系统设置，但不要贴着这个上限用，留一半余量比较稳。
4.3 坑三：高 DPI 下点击位置整体偏移
现象：在 125% 或 150% 缩放的显示器上，点击位置比预期偏右下。
原因：进程没有声明 DPI 感知，Windows 对进程做了 DPI 虚拟化，GetSystemMetrics返回的是虚拟化后的分辨率，而SendInput的坐标按物理像素解释，两者不一致。
解决：在程序入口加 DPI 感知声明，或者在项目清单文件里设置。代码方式是在main或WinMain最前面调SetProcessDpiAwarenessContext(DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2)。加完之后GetSystemMetrics和SendInput的坐标系就统一了。这个坑在单屏 100% 缩放时完全看不出来，一换显示器就暴露。
4.4 坑四：多显示器下坐标算错
现象：副屏上的目标点，点击落到了主屏对应位置。
原因：归一化公式只用了主屏分辨率SM_CXSCREEN，没有考虑虚拟屏幕的起点和总范围。副屏在主屏左侧时，虚拟屏幕原点可能是负值。
解决：用SM_XVIRTUALSCREEN、SM_YVIRTUALSCREEN、SM_CXVIRTUALSCREEN、SM_CYVIRTUALSCREEN拿虚拟屏幕的起点和尺寸，归一化时先减去起点再除以尺寸。这样无论目标在哪个屏，坐标都能对上。
4.5 坑五：Sleep 精度不够导致时序抖动
现象：双击偶尔成功偶尔失败，间隔看起来设了 120 毫秒，实际有时到 300 毫秒。
原因：Sleep的精度受系统时钟节拍影响，默认约 15.6 毫秒，且会被其他线程调度打断。在高负载机器上抖动更大。
解决：对时序要求高的场景，用timeBeginPeriod(1)提高时钟精度，用完timeEndPeriod(1)恢复。或者改用忙等待加QueryPerformanceCounter做精确间隔。但要注意timeBeginPeriod会增加系统功耗，不要长期开着。我一般只在双击这种短时序操作前后包一层。
5. 进阶：把点击封装成可复用、可验证的模块
前面讲的都是单点实现，真正做项目时，我会把点击逻辑封装成一个类，把坐标换算、焦点激活、时序控制、失败重试都收进去。这样调用方只需要传目标窗口和坐标，不用关心底层细节。下面是一个简化版的封装思路。
class MouseSimulator { public: // 设置目标窗口，后续点击都相对于它的客户区 void SetTarget(HWND hwnd) { m_hwnd = hwnd; } // 单击客户区坐标 bool Click(int cx, int cy, int retry = 3) { for (int i = 0; i < retry; ++i) { if (!ForceForeground(m_hwnd)) { Sleep(50); continue; } POINT pt = { cx, cy }; ClientToScreen(m_hwnd, &pt); if (SimulateLeftClick(pt.x, pt.y)) return true; Sleep(80); } return false; } // 双击客户区坐标 bool DoubleClick(int cx, int cy, int intervalMs = 120, int retry = 3) { for (int i = 0; i < retry; ++i) { if (!ForceForeground(m_hwnd)) { Sleep(50); continue; } POINT pt = { cx, cy }; ClientToScreen(m_hwnd, &pt); if (SimulateDoubleClick(pt.x, pt.y, intervalMs)) return true; Sleep(80); } return false; } private: HWND m_hwnd = nullptr; };逻辑说明：SetTarget绑定目标窗口，Click和DoubleClick都先激活窗口再换算坐标，失败自动重试。重试之间加Sleep(80)给系统一点缓冲，避免连续失败时把事件队列打满。retry默认 3 次，覆盖偶发的焦点抢占。
参数说明：retry不要设太大，超过 5 次基本说明环境有问题，继续重试只是浪费时间。intervalMs只在双击时生效。如果目标窗口在点击过程中被关闭，ForceForeground会失败，重试也会失败，这时候应该由调用方检查窗口有效性，而不是靠重试硬扛。
验证方法上，我习惯在开发阶段加一个“回读”步骤：点击后用GetCursorPos确认鼠标位置，用WindowFromPoint确认目标点下的窗口句柄是不是预期窗口。这两个检查能快速区分“事件没发出去”和“发出去但发错了地方”。等逻辑稳定后再把回读去掉，减少开销。
最后说个习惯：所有涉及SendInput的代码，我都会在函数入口记录一次GetForegroundWindow()和GetCursorPos()，出错时对比日志，一眼就能看出是焦点问题还是坐标问题。这个习惯帮我省了无数次盲猜的时间。希望帮到你。
本文还有配套的精品资源，点击获取
