简介这份 C# 代码包围绕 Windows 平台的键盘与鼠标输入模拟展开基于 Windows Input Simulator 扩展了鼠标事件支持面向需要实现自动化输入、辅助测试或交互演示的 C# 开发者适合具备一定 Win32 与 C# 基础的中级读者。压缩包共 30 个文件约 93KB包含 12 个 cs 源码文件、4 个 dll 程序集、4 个 pdb 调试符号、4 个 txt 说明以及 xml、csproj 等项目配置源码与编译产物并存便于直接引用或二次修改。代码覆盖虚拟键码、鼠标标志、输入结构体与统一模拟入口等模块可帮助读者理解键盘按键的按下、释放与组合触发以及鼠标移动点击和扩展按钮的封装方式并据此搭建自己的输入模拟工具或排查调用问题。许可采用 Microsoft Public License (Ms-PL)在使用和分发时需留意相应条款压缩包内附调试符号与说明文本便于定位运行问题、核对接口用途。已有 1182 人学习适合作为 Windows 输入模拟方向的参考实现。1. 前台窗口收不到按键先看这份 C# 键盘鼠标模拟库的定位跑 UI 自动化的同学习惯性地写一句SendKeys.SendWait(...)本地调试一切正常挂到目标程序上却像石头沉进水里——按键没反应或者干脆打进了自己进程的窗口。这类现象九成不是代码逻辑写错而是在「输入注入」这一层选错了工具SendKeys 依赖目标窗口的消息循环SendInput 走的是系统输入队列两者在权限、焦点、时序上的表现完全不同。键盘 鼠标 Input Simulator C# 这套封装的价值就在这儿它把 Win32 的SendInput包成KeyPress、TextEntry、MoveMouseTo这类一行调用省掉手写INPUT结构体和平台位数对齐的麻烦。它适合做自动化测试、批量录入、远程控制端、宏工具这类「操作本机真实界面」的场景不适合需要对抗检测的场合。2. 选 SendInput 封装而不是 SendKeys四条输入路线的边界对照在动手之前先把几条看起来都能「模拟按键」的路子摆在一起比一比。很多人踩的第一个坑不是 API 用错而是压根选错了注入层级——用消息级别的方案去驱动一个只认硬件输入队列的程序怎么调参数都没用。2.1 四条路线各自能覆盖到哪里路线注入点能否驱动非前台窗口中文/Unicode 文本权限要求主要短板SendKeys窗口消息WM_CHAR理论上可以实际极易失焦依赖当前键盘布局低焦点一变就丢长文本容易截断keybd_event/mouse_event系统输入队列旧 API否注入到前台需自行处理低已被标记为兼容保留串行调用开销大SendInput封装系统输入队列新 API否注入到前台支持KEYEVENTF_UNICODE需与被控窗口同级或更高受 UIPI、会话状态限制UI Automation控件树接口InvokePattern 等是支持中只对标准控件有效自绘界面无效表格里最右边一列才是决策依据。如果目标程序是标准 Win32 控件、又不想抢焦点UI Automation 更稳如果是自绘界面、游戏客户端、远程桌面这类「只认底层输入」的程序就只能走SendInput。SendKeys的位置很尴尬——它快、代码短但只适合对可靠性要求不高的干跑脚本。2.2 INPUT 结构体与注入模型封装层替你挡住了什么SendInput的签名看着简单传一个INPUT数组和数组长度返回实际注入的事件数。麻烦全在INPUT结构体本身——它是一个联合体键盘事件、鼠标事件、硬件事件共用同一块内存而cbSize字段必须精确等于当前平台下结构体的大小。32 位进程算出来是 28 字节64 位进程是 40 字节写死任何一个值另一边就会返回 0 并且GetLastError给你一个ERROR_INVALID_PARAMETER。封装库内部通常这么处理// 库内部的典型写法理解它比记住 API 更重要 [StructLayout(LayoutKind.Sequential)] struct INPUT { public uint type; // 0鼠标 1键盘 2硬件 public InputUnion u; public static int Size Marshal.SizeOf(typeof(INPUT)); } // 调用前按运行时位数取大小而不是写常量 var inputs new INPUT[1]; uint sent SendInput(1, inputs, INPUT.Size); if (sent ! 1) { // 注入失败一定要取错误码多数现场问题都靠这一行定位 int err Marshal.GetLastWin32Error(); throw new Win32Exception(err); }逻辑说明type字段决定联合体里哪一部分生效键盘事件填 1 并把KEYBDINPUT塞进联合体Size用Marshal.SizeOf在运行时计算避免 AnyCPU 编译后在 64 位机器上翻车。参数说明SendInput的第三个参数不是可选项传 0 会直接失败第二个参数是数组指针批量发送时一次性提交系统按顺序处理中间被打断的概率比逐个调用低得多这也是它比keybd_event靠谱的核心原因——一批事件在一次调用里完成不会出现「按下 A 还没来得及抬起另一个线程插进来发了 B」。2.3 引入库并跑通最小验证拿到这个资源后第一件事不是读完全部 API而是写一个十行的验证程序确认「库能编译、能注入、目标窗口能收到」这条链路是通的。using WindowsInput; using WindowsInput.Native; class Program { static void Main() { var sim new InputSimulator(); // 1) 先发一个单键验证基础链路 sim.Keyboard.KeyPress(VirtualKeyCode.VK_A); // 2) 再发一段文本验证 Unicode 通道 sim.Keyboard.TextEntry(hello-123); // 3) 最后验证组合键这一步最容易暴露时序问题 sim.Keyboard.ModifiedKeyStroke(VirtualKeyCode.CONTROL, VirtualKeyCode.VK_C); } }逻辑说明三步分别对应键盘模拟的三个层级——单键、文本、修饰键组合。单键走的是虚拟键码映射文本走的是 Unicode 逐字符注入组合键走的是「按下修饰键 → 按下主键 → 抬起主键 → 抬起修饰键」的四段序列。参数说明VirtualKeyCode是库里的枚举命名风格是VK_A、RETURN、CONTROL、MENU对应 Alt、LWINModifiedKeyStroke的第一个参数可以传单个枚举也可以传一个IEnumerableVirtualKeyCode来表示 CtrlShift 这种多修饰键第二个参数是主键。提示跑这段代码前先把光标点进一个空白文本框并且确认那个窗口是前台。SendInput不认窗口句柄它只往前台线程的输入队列里塞事件焦点在谁身上就进谁的口袋。2.4 什么情况下这个库解决不了问题有三类需求要在选型阶段就劝退需要后台静默操作非前台窗口的需要绕过目标程序输入检测的需要在锁屏或无人值守会话里稳定运行的。前两类分别属于 UI Automation 和驱动层的范畴第三类根本无解——没有交互式桌面时SendInput必然返回 0。把这三种场景排除掉剩下的自动化测试、表单批量填写、远程协助控制端、演示脚本录制回放才是这个库的主场。3. 键盘模拟虚拟键码、按住时长与 Unicode 文本的三条通道键盘这块最容易出问题的地方是很多人以为「发个字母」只有一种方式。实际上库里有三条不同的注入通道走错通道的表现是「代码不报错、目标程序没反应」排查起来极其费时。3.1 虚拟键码的边界字母数字之外那些键怎么写VirtualKeyCode枚举覆盖了绝大多数标准键但命名不统一写代码时容易凭直觉猜错。常用的对应关系值得单独记一下回车是RETURN不是ENTER退格是BACK制表符是TABEsc 是ESCAPE方向键是UP/DOWN/LEFT/RIGHT功能键是F1到F24。修饰键的命名更反直觉——Alt 对应的是MENU因为历史原因沿用了菜单键的叫法Win 键是LWIN和RWIN。var sim new InputSimulator(); // 常用功能键的写法注意 RETURN 和 MENU 这两个坑 sim.Keyboard.KeyPress(VirtualKeyCode.RETURN); // 回车 sim.Keyboard.KeyPress(VirtualKeyCode.TAB); // 制表符表单跳转必用 sim.Keyboard.KeyPress(VirtualKeyCode.MENU); // Alt sim.Keyboard.KeyPress(VirtualKeyCode.F5); // 刷新 // 组合键CtrlShiftEsc 这种多修饰键的写法 sim.Keyboard.ModifiedKeyStroke( new[] { VirtualKeyCode.CONTROL, VirtualKeyCode.SHIFT }, VirtualKeyCode.ESCAPE);逻辑说明ModifiedKeyStroke内部会先把所有修饰键依次按下再按主键然后逆序抬起这个顺序不能乱——如果先抬修饰键再抬主键目标程序可能把后半段识别成一次独立的按键。参数说明传数组时注意顺序系统对修饰键的按下顺序不敏感但抬起顺序必须严格逆序库内部已经处理好了自己用KeyDown/KeyUp手搓时一定要照做。3.2 短按、长按与按下抬起分离KeyPress是一个原子操作内部完成「按下、极短延时、抬起」。但有些场景需要真实的按住时长比如游戏里的持续移动、某些程序的长按菜单、拖动式选择。这时候要用KeyDown和KeyUp拆开。var sim new InputSimulator(); // 按住 Shift 再点鼠标做区间选择 sim.Keyboard.KeyDown(VirtualKeyCode.SHIFT); Thread.Sleep(50); // 给目标程序一点反应时间 sim.Mouse.LeftButtonClick(); Thread.Sleep(50); sim.Keyboard.KeyUp(VirtualKeyCode.SHIFT); // 长按方向键做连续移动 sim.Keyboard.KeyDown(VirtualKeyCode.RIGHT); Thread.Sleep(800); // 按住 800ms sim.Keyboard.KeyUp(VirtualKeyCode.RIGHT));逻辑说明KeyDown和KeyUp必须成对出现中间任何异常抛出都会留下一个「卡住」的键目标程序会一直认为这个键处于按下状态后续所有输入都会带上这个修饰键现象是「怎么打字都变成大写」或者「鼠标点击变成框选」。参数说明Thread.Sleep的时长不是越长越好50ms 是个经验起点太短目标程序来不及处理太长会让整体脚本变慢长按场景的时长取决于目标程序自己的重复触发阈值先在目标程序上手工按住测一下再决定脚本参数。注意所有KeyDown都应该包在try/finally里finally中无条件KeyUp。这条血泪经验来自一次批量脚本跑到一半崩溃最后机器上残留了三个按下的修饰键只能重启会话才恢复。3.3 文本输入走 Unicode 通道而不是逐键模拟TextEntry和连续KeyPress的区别是初学者最容易忽略的一点。前者走的是KEYEVENTF_UNICODE通道直接把 UTF-16 码元塞进输入队列不经过键盘布局映射后者是把每个字符翻译成虚拟键码再发出去遇到中文、日文、特殊符号、带重音的拉丁字母就会失败——因为当前键盘布局里根本没有那个键。var sim new InputSimulator(); // 中文、符号、混合内容都走这一条 sim.Keyboard.TextEntry(订单编号A-2024-0917); sim.Keyboard.TextEntry(特殊字符 ~!#$%^*()_); // 逐键模拟只适合确定的英文按键序列 sim.Keyboard.KeyPress(VirtualKeyCode.VK_H); sim.Keyboard.KeyPress(VirtualKeyCode.VK_I);逻辑说明TextEntry内部对字符串逐个char生成一条键盘事件wScan填字符码、wVk填 0、标志位带上KEYEVENTF_UNICODE系统收到后直接当作文本插入完全绕开键盘布局。参数说明这个方法对 BMP 范围内的字符中文、日文、韩文、大部分符号都能正确处理对于需要两个char表示的代理对部分生僻字、表情符号部分版本的实现会拆成两个独立事件目标程序可能显示成两个问号遇到这种字符建议先单独测一条。另外TextEntry的速度取决于目标控件的处理能力一次塞几百个字符到老式输入框里丢字符是常态需要分批并加延时。3.4 扫描码通道为什么有些程序不认虚拟键码还有一类目标程序KeyPress发过去毫无反应TextEntry也没用。这类程序通常直接读键盘扫描码DirectInput 那一套根本不看虚拟键码字段。库的标准 API 覆盖不到这个层级需要自己补一段 P/Invoke把MapVirtualKey拿到的扫描码填进KEYBDINPUT并带上KEYEVENTF_SCANCODE标志。// 扩展思路虚拟键码转扫描码后走扫描码通道 uint scanCode MapVirtualKey((uint)VirtualKeyCode.VK_W, 0); // 0 MAPVK_VK_TO_VSC var input new INPUT { type 1, u new InputUnion { ki new KEYBDINPUT { wVk 0, // 关键用扫描码时虚拟键码必须为 0 wScan (ushort)scanCode, dwFlags 0x0008, // KEYEVENTF_SCANCODE time 0, dwExtraInfo IntPtr.Zero } } };逻辑说明wVk置 0 是关键如果同时填了虚拟键码和扫描码系统会优先按虚拟键码处理扫描码通道就失效了。参数说明MapVirtualKey的第二个参数 0 表示「虚拟键码转扫描码」反过来的映射用 1扩展键方向键、小键盘回车、右 Ctrl还需要额外加上KEYEVENTF_EXTENDEDKEY0x0001否则目标程序收到的键值会和预期差一截。4. 鼠标模拟坐标归一化、按键组合与多屏适配鼠标这部分看起来比键盘简单——不就是移动和点击吗。真正上手会发现坐标是最容易翻车的地方尤其是接了第二块显示器或者系统缩放不是 100% 的机器同一份代码在本机好好的到同事电脑上点到了屏幕外面。4.1 屏幕坐标到 0~65535 的归一化换算SendInput的鼠标移动事件不接受像素坐标它要的是把屏幕映射到 0 到 65535 区间后的绝对值。库里的MoveMouseTo就是干这个转换的常见实现是把目标像素乘上65535.0 / 屏幕宽度再四舍五入。var sim new InputSimulator(); // 移动到主屏 (960, 540) 这个点 sim.Mouse.MoveMouseTo(960, 540); // 相对移动从当前位置右移 100 像素、下移 50 像素 sim.Mouse.MoveMouseBy(100, 50);逻辑说明MoveMouseTo是绝对值语义内部会拼上MOUSEEVENTF_MOVE | MOUSEEVENTF_ABSOLUTE并把像素坐标归一化MoveMouseBy是相对值语义只带MOUSEEVENTF_MOVEdx/dy直接就是像素增量。参数说明归一化的分母是主显示器的宽高不是虚拟桌面的总宽高这一点决定了多屏场景的行为下一节展开。另外归一化本身有精度损失1920 宽的屏幕上理论误差不到一个像素但 3840 宽时误差会被放大需要精确落点的场景比如点小图标建议移动后再用GetCursorPos回读校验。4.2 点击、双击、拖拽与滚轮点击类 API 按按钮和次数分了几个变体命名很直白LeftButtonClick、LeftButtonDoubleClick、RightButtonClick、MiddleButtonClick以及对应的Down/Up版本。滚轮是VerticalScroll参数单位是「行」正数向上。var sim new InputSimulator(); // 单击与双击 sim.Mouse.LeftButtonClick(); Thread.Sleep(120); // 双击间隔要小于系统阈值否则会被拆成两次单击 sim.Mouse.LeftButtonDoubleClick(); // 拖拽按下 - 分多次移动 - 抬起 sim.Mouse.MoveMouseTo(400, 300); sim.Mouse.LeftButtonDown(); for (int i 1; i 10; i) { sim.Mouse.MoveMouseTo(400 i * 30, 300 i * 10); Thread.Sleep(15); // 分步移动一次性跳过去目标程序可能识别不到拖拽 } sim.Mouse.LeftButtonUp(); // 滚轮向下滚 3 行 sim.Mouse.VerticalScroll(-3);逻辑说明拖拽必须分步移动很多程序尤其是图形编辑器和列表控件靠连续的鼠标移动事件来判断「这是一次拖拽」而不是「一次跳转后按下」一步到位会失败。参数说明双击间隔受系统「双击速度」设置控制默认 500ms 左右脚本里给 120ms 比较安全VerticalScroll的单位是行不是像素一次传 3 表示滚三行不同程序对行的像素高度定义不同实际滚动距离会有差异。4.3 多显示器与 DPI 缩放坐标系统的两层换算这是鼠标部分最大的坑源。MoveMouseTo的归一化通常以主显示器的分辨率做分母而GetCursorPos返回的是虚拟桌面坐标系两者在多屏且副屏在主屏左侧或上方时会对不上——因为虚拟桌面坐标可以有负值。// 拿到虚拟桌面的整体边界用于坐标换算 int vx GetSystemMetrics(SM_XVIRTUALSCREEN); // 0x4C int vy GetSystemMetrics(SM_YVIRTUALSCREEN); // 0x4D int vw GetSystemMetrics(SM_CXVIRTUALSCREEN); // 0x4E int vh GetSystemMetrics(SM_CYVIRTUALSCREEN); // 0x4F // 目标像素坐标 (px, py) 换算成虚拟桌面内的相对坐标 double relX (px - vx) * 65535.0 / (vw - 1); double relY (py - vy) * 65535.0 / (vh - 1);逻辑说明SM_XVIRTUALSCREEN系列返回的是整个虚拟桌面的左上角坐标和总尺寸副屏在主屏左侧时vx是负数直接用主屏尺寸做分母必然偏。参数说明分母用vw - 1而不是vw是为了让最右侧像素能映射到 65535 这个端点少减这个 1 会导致屏幕最右一列永远点不到。DPI 缩放是另一层问题——进程不声明 DPI 感知时系统会对坐标做一次隐式缩放1920 的屏幕在 150% 缩放下报告的逻辑分辨率是 1280脚本按 1920 算就会点偏。解决办法是在应用清单里声明PerMonitorV2让进程拿到物理像素。提示写涉及鼠标定位的脚本第一行永远先打印GetSystemMetrics的四个值跟目标机器的实际情况对一遍。这个习惯帮我省掉了至少一半「明明坐标没错就是点不到」的排查时间。5. 五个翻车现场权限、焦点、时序的排查清单前面几章讲的都是「正确路径」这一章讲的是「错误路径长什么样」。下面五条都是我在真实脚本里撞过的现象、原因、解决按顺序写清楚遇到同类问题可以直接对号入座。5.1 权限不对等被 UIPI 静默拦截现象脚本对本程序窗口发按键一切正常换成某个需要管理员权限的目标程序就完全没反应SendInput的返回值却显示注入成功没有任何异常。原因Windows 的 UIPI用户界面特权隔离机制规定低完整性级别的进程不能向高完整性级别的窗口注入输入。你的脚本以普通权限运行目标程序以管理员权限运行注入事件在进入目标窗口的消息队列前就被丢弃了SendInput只是把事件塞进了系统队列它不负责投递成功。解决让脚本以与目标程序相同或更高的权限运行。在应用清单里设置requestedExecutionLevel为requireAdministrator或者由启动器以管理员身份拉起。这里有个连带坑——脚本提权后它自己拉的子进程、它读取的配置目录、它写入的日志目录都会跟着变路径写死的脚本会在提权后找不到文件。5.2 焦点被抢输入打进了错误的窗口现象脚本前几次运行正常跑一会儿开始丢按键日志里没有任何错误或者批量处理多个窗口时总有几个窗口收到的输入串到别的窗口去了。原因SendInput注入的是「当前前台线程的输入队列」脚本调用和实际注入之间存在时间差这段时间里如果用户切了窗口、或者目标程序自己弹了个对话框抢了焦点输入就进了别人家。另外SetForegroundWindow本身也有限制非前台进程调用它时系统可能只是让任务栏图标闪烁而不真正切换。解决每次发输入前先校验GetForegroundWindow()的返回值是否等于目标句柄不等就SetForegroundWindow后重试重试两三次仍失败就跳过这一条并记录日志。更稳的办法是把脚本设计成「一次性只处理一个前台窗口」全程不依赖用户不碰键盘鼠标而不是在后台跟用户抢焦点。5.3 时序太快丢字符与粘键现象TextEntry发了三十个字符目标输入框里只出现二十来个或者组合键偶尔退化成单独的按键比如 CtrlC 变成了先按 C 再按 Ctrl。原因目标程序的 UI 线程处理输入事件需要时间输入队列积压到一定程度某些控件会丢事件组合键退化则是上一个操作的KeyUp还没被处理下一个KeyDown就到了目标程序按自己的节奏解析时顺序就乱了。解决把长文本切成 20 到 50 字符一段段间Thread.Sleep(30)组合键操作之间至少留 50ms对可靠性要求极高的场景可以在每次操作后回读目标控件的内容通过 UI Automation 的ValuePattern或者读剪贴板确认生效再继续而不是盲目往下跑。5.4 锁屏或会话断开时静默失效现象白天手动跑得好好的脚本设成凌晨定时任务后全部失败日志里SendInput返回 0或者干脆连返回都没记录到。原因锁屏、切换用户、断开远程桌面之后进程还在但已经没有交互式桌面了。SendInput需要一个活动的输入桌面才能工作没有就直接失败。这不是权限问题提权也救不回来。解决定时任务勾选「只在用户登录时运行」并且确保任务执行期间会话保持解锁如果必须无人值守就得换思路用 UI Automation 的后台模式或者干脆改成直接操作数据层而不是操作界面。这个坑没有优雅的绕法承认它并调整方案比硬刚更省时间。5.5 平台目标与结构体对齐现象同一份代码x86 编译运行正常AnyCPU 在 64 位机器上跑就注入失败错误码是参数无效。原因INPUT结构体的大小随平台位数变化自定义 P/Invoke 声明如果写死了 28 或者用错了StructLayout64 位下cbSize就对不上SendInput直接拒绝。封装库自己会处理但只要你在它之上补了任何自定义的 P/Invoke比如上一章的扫描码扩展就必须自己保证Marshal.SizeOf在运行时计算。解决所有自定义结构体都用Marshal.SizeOf(typeof(T))取大小不要写常量StructLayout用Sequential不加Pack如果项目必须支持 AnyCPU在 CI 里同时跑 x86 和 x64 两套冒烟测试别等上线才发现。6. 把调用收进一个门面重试、回读与节奏控制散落在业务代码里的sim.Keyboard.KeyPress(...)到了一定规模就没法维护了参数调一次要翻十个文件。我的做法是包一层薄门面把重试、异常兜底、节奏控制集中在一处业务侧只描述「做什么」不描述「怎么发」。public sealed class InputFacade { private readonly InputSimulator _sim new InputSimulator(); private readonly int _intervalMs; public InputFacade(int intervalMs 40) _intervalMs intervalMs; // 带重试的按键失败时重发仍失败则抛出避免静默丢输入 public bool TryKey(VirtualKeyCode key, int retry 2) { for (int i 0; i retry; i) { try { _sim.Keyboard.KeyPress(key); Thread.Sleep(_intervalMs); return true; } catch (Exception ex) when (i retry) { Log($[retry {i}] key{key} err{ex.Message}); Thread.Sleep(_intervalMs * 3); // 退避后再试 } } return false; } // 长文本分段发送段间留间隔降低丢字符概率 public void TypeText(string text, int chunk 40) { for (int i 0; i text.Length; i chunk) { string part text.Substring(i, Math.Min(chunk, text.Length - i)); _sim.Keyboard.TextEntry(part); Thread.Sleep(_intervalMs); } } }逻辑说明TryKey把「发送、等待、失败退避重试」封在一起调用方拿到布尔值就能判断是否继续不用在每个调用点写 try-catch。TypeText的分段逻辑解决的是 5.3 里那个丢字符问题chunk参数按目标控件的处理能力调现代浏览器里的输入框可以给 100老式 Win32 编辑框给 20 更稳。参数说明intervalMs是全局节奏40ms 是一个兼顾速度和稳定性的起点重试的退避倍数给 3 倍是为了给目标程序留出把队列排空的时间退避太短等于没退。验证环节不要靠肉眼看。文本类操作发完之后回读一次目标控件的内容做比对鼠标类操作发完之后用GetCursorPos读回实际坐标和预期坐标对比按键类操作可以在目标程序里挂一个轻量的键盘钩子记录实际收到的键序列。这套自检写起来二十分钟能省掉后面几十次「到底发出去没有」的猜谜。这些参数没有普适值。我现在的习惯是每接一个新目标程序先用一个最小脚本把间隔从 10ms 往上试记录第一次稳定不丢的数值再乘 2 作为正式参数——那次批量录入跑了两千条才发现最后三百条全是重复的就是因为间隔贴着临界值前面快后面慢从那以后每次定节奏我都强制走一遍加压测试。希望帮到你。本文还有配套的精品资源点击获取
简介这份 C# 代码包围绕 Windows 平台的键盘与鼠标输入模拟展开基于 Windows Input Simulator 扩展了鼠标事件支持面向需要实现自动化输入、辅助测试或交互演示的 C# 开发者适合具备一定 Win32 与 C# 基础的中级读者。压缩包共 30 个文件约 93KB包含 12 个 cs 源码文件、4 个 dll 程序集、4 个 pdb 调试符号、4 个 txt 说明以及 xml、csproj 等项目配置源码与编译产物并存便于直接引用或二次修改。代码覆盖虚拟键码、鼠标标志、输入结构体与统一模拟入口等模块可帮助读者理解键盘按键的按下、释放与组合触发以及鼠标移动点击和扩展按钮的封装方式并据此搭建自己的输入模拟工具或排查调用问题。许可采用 Microsoft Public License (Ms-PL)在使用和分发时需留意相应条款压缩包内附调试符号与说明文本便于定位运行问题、核对接口用途。已有 1182 人学习适合作为 Windows 输入模拟方向的参考实现。1. 前台窗口收不到按键先看这份 C# 键盘鼠标模拟库的定位跑 UI 自动化的同学习惯性地写一句SendKeys.SendWait(...)本地调试一切正常挂到目标程序上却像石头沉进水里——按键没反应或者干脆打进了自己进程的窗口。这类现象九成不是代码逻辑写错而是在「输入注入」这一层选错了工具SendKeys 依赖目标窗口的消息循环SendInput 走的是系统输入队列两者在权限、焦点、时序上的表现完全不同。键盘 鼠标 Input Simulator C# 这套封装的价值就在这儿它把 Win32 的SendInput包成KeyPress、TextEntry、MoveMouseTo这类一行调用省掉手写INPUT结构体和平台位数对齐的麻烦。它适合做自动化测试、批量录入、远程控制端、宏工具这类「操作本机真实界面」的场景不适合需要对抗检测的场合。2. 选 SendInput 封装而不是 SendKeys四条输入路线的边界对照在动手之前先把几条看起来都能「模拟按键」的路子摆在一起比一比。很多人踩的第一个坑不是 API 用错而是压根选错了注入层级——用消息级别的方案去驱动一个只认硬件输入队列的程序怎么调参数都没用。2.1 四条路线各自能覆盖到哪里路线注入点能否驱动非前台窗口中文/Unicode 文本权限要求主要短板SendKeys窗口消息WM_CHAR理论上可以实际极易失焦依赖当前键盘布局低焦点一变就丢长文本容易截断keybd_event/mouse_event系统输入队列旧 API否注入到前台需自行处理低已被标记为兼容保留串行调用开销大SendInput封装系统输入队列新 API否注入到前台支持KEYEVENTF_UNICODE需与被控窗口同级或更高受 UIPI、会话状态限制UI Automation控件树接口InvokePattern 等是支持中只对标准控件有效自绘界面无效表格里最右边一列才是决策依据。如果目标程序是标准 Win32 控件、又不想抢焦点UI Automation 更稳如果是自绘界面、游戏客户端、远程桌面这类「只认底层输入」的程序就只能走SendInput。SendKeys的位置很尴尬——它快、代码短但只适合对可靠性要求不高的干跑脚本。2.2 INPUT 结构体与注入模型封装层替你挡住了什么SendInput的签名看着简单传一个INPUT数组和数组长度返回实际注入的事件数。麻烦全在INPUT结构体本身——它是一个联合体键盘事件、鼠标事件、硬件事件共用同一块内存而cbSize字段必须精确等于当前平台下结构体的大小。32 位进程算出来是 28 字节64 位进程是 40 字节写死任何一个值另一边就会返回 0 并且GetLastError给你一个ERROR_INVALID_PARAMETER。封装库内部通常这么处理// 库内部的典型写法理解它比记住 API 更重要 [StructLayout(LayoutKind.Sequential)] struct INPUT { public uint type; // 0鼠标 1键盘 2硬件 public InputUnion u; public static int Size Marshal.SizeOf(typeof(INPUT)); } // 调用前按运行时位数取大小而不是写常量 var inputs new INPUT[1]; uint sent SendInput(1, inputs, INPUT.Size); if (sent ! 1) { // 注入失败一定要取错误码多数现场问题都靠这一行定位 int err Marshal.GetLastWin32Error(); throw new Win32Exception(err); }逻辑说明type字段决定联合体里哪一部分生效键盘事件填 1 并把KEYBDINPUT塞进联合体Size用Marshal.SizeOf在运行时计算避免 AnyCPU 编译后在 64 位机器上翻车。参数说明SendInput的第三个参数不是可选项传 0 会直接失败第二个参数是数组指针批量发送时一次性提交系统按顺序处理中间被打断的概率比逐个调用低得多这也是它比keybd_event靠谱的核心原因——一批事件在一次调用里完成不会出现「按下 A 还没来得及抬起另一个线程插进来发了 B」。2.3 引入库并跑通最小验证拿到这个资源后第一件事不是读完全部 API而是写一个十行的验证程序确认「库能编译、能注入、目标窗口能收到」这条链路是通的。using WindowsInput; using WindowsInput.Native; class Program { static void Main() { var sim new InputSimulator(); // 1) 先发一个单键验证基础链路 sim.Keyboard.KeyPress(VirtualKeyCode.VK_A); // 2) 再发一段文本验证 Unicode 通道 sim.Keyboard.TextEntry(hello-123); // 3) 最后验证组合键这一步最容易暴露时序问题 sim.Keyboard.ModifiedKeyStroke(VirtualKeyCode.CONTROL, VirtualKeyCode.VK_C); } }逻辑说明三步分别对应键盘模拟的三个层级——单键、文本、修饰键组合。单键走的是虚拟键码映射文本走的是 Unicode 逐字符注入组合键走的是「按下修饰键 → 按下主键 → 抬起主键 → 抬起修饰键」的四段序列。参数说明VirtualKeyCode是库里的枚举命名风格是VK_A、RETURN、CONTROL、MENU对应 Alt、LWINModifiedKeyStroke的第一个参数可以传单个枚举也可以传一个IEnumerableVirtualKeyCode来表示 CtrlShift 这种多修饰键第二个参数是主键。提示跑这段代码前先把光标点进一个空白文本框并且确认那个窗口是前台。SendInput不认窗口句柄它只往前台线程的输入队列里塞事件焦点在谁身上就进谁的口袋。2.4 什么情况下这个库解决不了问题有三类需求要在选型阶段就劝退需要后台静默操作非前台窗口的需要绕过目标程序输入检测的需要在锁屏或无人值守会话里稳定运行的。前两类分别属于 UI Automation 和驱动层的范畴第三类根本无解——没有交互式桌面时SendInput必然返回 0。把这三种场景排除掉剩下的自动化测试、表单批量填写、远程协助控制端、演示脚本录制回放才是这个库的主场。3. 键盘模拟虚拟键码、按住时长与 Unicode 文本的三条通道键盘这块最容易出问题的地方是很多人以为「发个字母」只有一种方式。实际上库里有三条不同的注入通道走错通道的表现是「代码不报错、目标程序没反应」排查起来极其费时。3.1 虚拟键码的边界字母数字之外那些键怎么写VirtualKeyCode枚举覆盖了绝大多数标准键但命名不统一写代码时容易凭直觉猜错。常用的对应关系值得单独记一下回车是RETURN不是ENTER退格是BACK制表符是TABEsc 是ESCAPE方向键是UP/DOWN/LEFT/RIGHT功能键是F1到F24。修饰键的命名更反直觉——Alt 对应的是MENU因为历史原因沿用了菜单键的叫法Win 键是LWIN和RWIN。var sim new InputSimulator(); // 常用功能键的写法注意 RETURN 和 MENU 这两个坑 sim.Keyboard.KeyPress(VirtualKeyCode.RETURN); // 回车 sim.Keyboard.KeyPress(VirtualKeyCode.TAB); // 制表符表单跳转必用 sim.Keyboard.KeyPress(VirtualKeyCode.MENU); // Alt sim.Keyboard.KeyPress(VirtualKeyCode.F5); // 刷新 // 组合键CtrlShiftEsc 这种多修饰键的写法 sim.Keyboard.ModifiedKeyStroke( new[] { VirtualKeyCode.CONTROL, VirtualKeyCode.SHIFT }, VirtualKeyCode.ESCAPE);逻辑说明ModifiedKeyStroke内部会先把所有修饰键依次按下再按主键然后逆序抬起这个顺序不能乱——如果先抬修饰键再抬主键目标程序可能把后半段识别成一次独立的按键。参数说明传数组时注意顺序系统对修饰键的按下顺序不敏感但抬起顺序必须严格逆序库内部已经处理好了自己用KeyDown/KeyUp手搓时一定要照做。3.2 短按、长按与按下抬起分离KeyPress是一个原子操作内部完成「按下、极短延时、抬起」。但有些场景需要真实的按住时长比如游戏里的持续移动、某些程序的长按菜单、拖动式选择。这时候要用KeyDown和KeyUp拆开。var sim new InputSimulator(); // 按住 Shift 再点鼠标做区间选择 sim.Keyboard.KeyDown(VirtualKeyCode.SHIFT); Thread.Sleep(50); // 给目标程序一点反应时间 sim.Mouse.LeftButtonClick(); Thread.Sleep(50); sim.Keyboard.KeyUp(VirtualKeyCode.SHIFT); // 长按方向键做连续移动 sim.Keyboard.KeyDown(VirtualKeyCode.RIGHT); Thread.Sleep(800); // 按住 800ms sim.Keyboard.KeyUp(VirtualKeyCode.RIGHT));逻辑说明KeyDown和KeyUp必须成对出现中间任何异常抛出都会留下一个「卡住」的键目标程序会一直认为这个键处于按下状态后续所有输入都会带上这个修饰键现象是「怎么打字都变成大写」或者「鼠标点击变成框选」。参数说明Thread.Sleep的时长不是越长越好50ms 是个经验起点太短目标程序来不及处理太长会让整体脚本变慢长按场景的时长取决于目标程序自己的重复触发阈值先在目标程序上手工按住测一下再决定脚本参数。注意所有KeyDown都应该包在try/finally里finally中无条件KeyUp。这条血泪经验来自一次批量脚本跑到一半崩溃最后机器上残留了三个按下的修饰键只能重启会话才恢复。3.3 文本输入走 Unicode 通道而不是逐键模拟TextEntry和连续KeyPress的区别是初学者最容易忽略的一点。前者走的是KEYEVENTF_UNICODE通道直接把 UTF-16 码元塞进输入队列不经过键盘布局映射后者是把每个字符翻译成虚拟键码再发出去遇到中文、日文、特殊符号、带重音的拉丁字母就会失败——因为当前键盘布局里根本没有那个键。var sim new InputSimulator(); // 中文、符号、混合内容都走这一条 sim.Keyboard.TextEntry(订单编号A-2024-0917); sim.Keyboard.TextEntry(特殊字符 ~!#$%^*()_); // 逐键模拟只适合确定的英文按键序列 sim.Keyboard.KeyPress(VirtualKeyCode.VK_H); sim.Keyboard.KeyPress(VirtualKeyCode.VK_I);逻辑说明TextEntry内部对字符串逐个char生成一条键盘事件wScan填字符码、wVk填 0、标志位带上KEYEVENTF_UNICODE系统收到后直接当作文本插入完全绕开键盘布局。参数说明这个方法对 BMP 范围内的字符中文、日文、韩文、大部分符号都能正确处理对于需要两个char表示的代理对部分生僻字、表情符号部分版本的实现会拆成两个独立事件目标程序可能显示成两个问号遇到这种字符建议先单独测一条。另外TextEntry的速度取决于目标控件的处理能力一次塞几百个字符到老式输入框里丢字符是常态需要分批并加延时。3.4 扫描码通道为什么有些程序不认虚拟键码还有一类目标程序KeyPress发过去毫无反应TextEntry也没用。这类程序通常直接读键盘扫描码DirectInput 那一套根本不看虚拟键码字段。库的标准 API 覆盖不到这个层级需要自己补一段 P/Invoke把MapVirtualKey拿到的扫描码填进KEYBDINPUT并带上KEYEVENTF_SCANCODE标志。// 扩展思路虚拟键码转扫描码后走扫描码通道 uint scanCode MapVirtualKey((uint)VirtualKeyCode.VK_W, 0); // 0 MAPVK_VK_TO_VSC var input new INPUT { type 1, u new InputUnion { ki new KEYBDINPUT { wVk 0, // 关键用扫描码时虚拟键码必须为 0 wScan (ushort)scanCode, dwFlags 0x0008, // KEYEVENTF_SCANCODE time 0, dwExtraInfo IntPtr.Zero } } };逻辑说明wVk置 0 是关键如果同时填了虚拟键码和扫描码系统会优先按虚拟键码处理扫描码通道就失效了。参数说明MapVirtualKey的第二个参数 0 表示「虚拟键码转扫描码」反过来的映射用 1扩展键方向键、小键盘回车、右 Ctrl还需要额外加上KEYEVENTF_EXTENDEDKEY0x0001否则目标程序收到的键值会和预期差一截。4. 鼠标模拟坐标归一化、按键组合与多屏适配鼠标这部分看起来比键盘简单——不就是移动和点击吗。真正上手会发现坐标是最容易翻车的地方尤其是接了第二块显示器或者系统缩放不是 100% 的机器同一份代码在本机好好的到同事电脑上点到了屏幕外面。4.1 屏幕坐标到 0~65535 的归一化换算SendInput的鼠标移动事件不接受像素坐标它要的是把屏幕映射到 0 到 65535 区间后的绝对值。库里的MoveMouseTo就是干这个转换的常见实现是把目标像素乘上65535.0 / 屏幕宽度再四舍五入。var sim new InputSimulator(); // 移动到主屏 (960, 540) 这个点 sim.Mouse.MoveMouseTo(960, 540); // 相对移动从当前位置右移 100 像素、下移 50 像素 sim.Mouse.MoveMouseBy(100, 50);逻辑说明MoveMouseTo是绝对值语义内部会拼上MOUSEEVENTF_MOVE | MOUSEEVENTF_ABSOLUTE并把像素坐标归一化MoveMouseBy是相对值语义只带MOUSEEVENTF_MOVEdx/dy直接就是像素增量。参数说明归一化的分母是主显示器的宽高不是虚拟桌面的总宽高这一点决定了多屏场景的行为下一节展开。另外归一化本身有精度损失1920 宽的屏幕上理论误差不到一个像素但 3840 宽时误差会被放大需要精确落点的场景比如点小图标建议移动后再用GetCursorPos回读校验。4.2 点击、双击、拖拽与滚轮点击类 API 按按钮和次数分了几个变体命名很直白LeftButtonClick、LeftButtonDoubleClick、RightButtonClick、MiddleButtonClick以及对应的Down/Up版本。滚轮是VerticalScroll参数单位是「行」正数向上。var sim new InputSimulator(); // 单击与双击 sim.Mouse.LeftButtonClick(); Thread.Sleep(120); // 双击间隔要小于系统阈值否则会被拆成两次单击 sim.Mouse.LeftButtonDoubleClick(); // 拖拽按下 - 分多次移动 - 抬起 sim.Mouse.MoveMouseTo(400, 300); sim.Mouse.LeftButtonDown(); for (int i 1; i 10; i) { sim.Mouse.MoveMouseTo(400 i * 30, 300 i * 10); Thread.Sleep(15); // 分步移动一次性跳过去目标程序可能识别不到拖拽 } sim.Mouse.LeftButtonUp(); // 滚轮向下滚 3 行 sim.Mouse.VerticalScroll(-3);逻辑说明拖拽必须分步移动很多程序尤其是图形编辑器和列表控件靠连续的鼠标移动事件来判断「这是一次拖拽」而不是「一次跳转后按下」一步到位会失败。参数说明双击间隔受系统「双击速度」设置控制默认 500ms 左右脚本里给 120ms 比较安全VerticalScroll的单位是行不是像素一次传 3 表示滚三行不同程序对行的像素高度定义不同实际滚动距离会有差异。4.3 多显示器与 DPI 缩放坐标系统的两层换算这是鼠标部分最大的坑源。MoveMouseTo的归一化通常以主显示器的分辨率做分母而GetCursorPos返回的是虚拟桌面坐标系两者在多屏且副屏在主屏左侧或上方时会对不上——因为虚拟桌面坐标可以有负值。// 拿到虚拟桌面的整体边界用于坐标换算 int vx GetSystemMetrics(SM_XVIRTUALSCREEN); // 0x4C int vy GetSystemMetrics(SM_YVIRTUALSCREEN); // 0x4D int vw GetSystemMetrics(SM_CXVIRTUALSCREEN); // 0x4E int vh GetSystemMetrics(SM_CYVIRTUALSCREEN); // 0x4F // 目标像素坐标 (px, py) 换算成虚拟桌面内的相对坐标 double relX (px - vx) * 65535.0 / (vw - 1); double relY (py - vy) * 65535.0 / (vh - 1);逻辑说明SM_XVIRTUALSCREEN系列返回的是整个虚拟桌面的左上角坐标和总尺寸副屏在主屏左侧时vx是负数直接用主屏尺寸做分母必然偏。参数说明分母用vw - 1而不是vw是为了让最右侧像素能映射到 65535 这个端点少减这个 1 会导致屏幕最右一列永远点不到。DPI 缩放是另一层问题——进程不声明 DPI 感知时系统会对坐标做一次隐式缩放1920 的屏幕在 150% 缩放下报告的逻辑分辨率是 1280脚本按 1920 算就会点偏。解决办法是在应用清单里声明PerMonitorV2让进程拿到物理像素。提示写涉及鼠标定位的脚本第一行永远先打印GetSystemMetrics的四个值跟目标机器的实际情况对一遍。这个习惯帮我省掉了至少一半「明明坐标没错就是点不到」的排查时间。5. 五个翻车现场权限、焦点、时序的排查清单前面几章讲的都是「正确路径」这一章讲的是「错误路径长什么样」。下面五条都是我在真实脚本里撞过的现象、原因、解决按顺序写清楚遇到同类问题可以直接对号入座。5.1 权限不对等被 UIPI 静默拦截现象脚本对本程序窗口发按键一切正常换成某个需要管理员权限的目标程序就完全没反应SendInput的返回值却显示注入成功没有任何异常。原因Windows 的 UIPI用户界面特权隔离机制规定低完整性级别的进程不能向高完整性级别的窗口注入输入。你的脚本以普通权限运行目标程序以管理员权限运行注入事件在进入目标窗口的消息队列前就被丢弃了SendInput只是把事件塞进了系统队列它不负责投递成功。解决让脚本以与目标程序相同或更高的权限运行。在应用清单里设置requestedExecutionLevel为requireAdministrator或者由启动器以管理员身份拉起。这里有个连带坑——脚本提权后它自己拉的子进程、它读取的配置目录、它写入的日志目录都会跟着变路径写死的脚本会在提权后找不到文件。5.2 焦点被抢输入打进了错误的窗口现象脚本前几次运行正常跑一会儿开始丢按键日志里没有任何错误或者批量处理多个窗口时总有几个窗口收到的输入串到别的窗口去了。原因SendInput注入的是「当前前台线程的输入队列」脚本调用和实际注入之间存在时间差这段时间里如果用户切了窗口、或者目标程序自己弹了个对话框抢了焦点输入就进了别人家。另外SetForegroundWindow本身也有限制非前台进程调用它时系统可能只是让任务栏图标闪烁而不真正切换。解决每次发输入前先校验GetForegroundWindow()的返回值是否等于目标句柄不等就SetForegroundWindow后重试重试两三次仍失败就跳过这一条并记录日志。更稳的办法是把脚本设计成「一次性只处理一个前台窗口」全程不依赖用户不碰键盘鼠标而不是在后台跟用户抢焦点。5.3 时序太快丢字符与粘键现象TextEntry发了三十个字符目标输入框里只出现二十来个或者组合键偶尔退化成单独的按键比如 CtrlC 变成了先按 C 再按 Ctrl。原因目标程序的 UI 线程处理输入事件需要时间输入队列积压到一定程度某些控件会丢事件组合键退化则是上一个操作的KeyUp还没被处理下一个KeyDown就到了目标程序按自己的节奏解析时顺序就乱了。解决把长文本切成 20 到 50 字符一段段间Thread.Sleep(30)组合键操作之间至少留 50ms对可靠性要求极高的场景可以在每次操作后回读目标控件的内容通过 UI Automation 的ValuePattern或者读剪贴板确认生效再继续而不是盲目往下跑。5.4 锁屏或会话断开时静默失效现象白天手动跑得好好的脚本设成凌晨定时任务后全部失败日志里SendInput返回 0或者干脆连返回都没记录到。原因锁屏、切换用户、断开远程桌面之后进程还在但已经没有交互式桌面了。SendInput需要一个活动的输入桌面才能工作没有就直接失败。这不是权限问题提权也救不回来。解决定时任务勾选「只在用户登录时运行」并且确保任务执行期间会话保持解锁如果必须无人值守就得换思路用 UI Automation 的后台模式或者干脆改成直接操作数据层而不是操作界面。这个坑没有优雅的绕法承认它并调整方案比硬刚更省时间。5.5 平台目标与结构体对齐现象同一份代码x86 编译运行正常AnyCPU 在 64 位机器上跑就注入失败错误码是参数无效。原因INPUT结构体的大小随平台位数变化自定义 P/Invoke 声明如果写死了 28 或者用错了StructLayout64 位下cbSize就对不上SendInput直接拒绝。封装库自己会处理但只要你在它之上补了任何自定义的 P/Invoke比如上一章的扫描码扩展就必须自己保证Marshal.SizeOf在运行时计算。解决所有自定义结构体都用Marshal.SizeOf(typeof(T))取大小不要写常量StructLayout用Sequential不加Pack如果项目必须支持 AnyCPU在 CI 里同时跑 x86 和 x64 两套冒烟测试别等上线才发现。6. 把调用收进一个门面重试、回读与节奏控制散落在业务代码里的sim.Keyboard.KeyPress(...)到了一定规模就没法维护了参数调一次要翻十个文件。我的做法是包一层薄门面把重试、异常兜底、节奏控制集中在一处业务侧只描述「做什么」不描述「怎么发」。public sealed class InputFacade { private readonly InputSimulator _sim new InputSimulator(); private readonly int _intervalMs; public InputFacade(int intervalMs 40) _intervalMs intervalMs; // 带重试的按键失败时重发仍失败则抛出避免静默丢输入 public bool TryKey(VirtualKeyCode key, int retry 2) { for (int i 0; i retry; i) { try { _sim.Keyboard.KeyPress(key); Thread.Sleep(_intervalMs); return true; } catch (Exception ex) when (i retry) { Log($[retry {i}] key{key} err{ex.Message}); Thread.Sleep(_intervalMs * 3); // 退避后再试 } } return false; } // 长文本分段发送段间留间隔降低丢字符概率 public void TypeText(string text, int chunk 40) { for (int i 0; i text.Length; i chunk) { string part text.Substring(i, Math.Min(chunk, text.Length - i)); _sim.Keyboard.TextEntry(part); Thread.Sleep(_intervalMs); } } }逻辑说明TryKey把「发送、等待、失败退避重试」封在一起调用方拿到布尔值就能判断是否继续不用在每个调用点写 try-catch。TypeText的分段逻辑解决的是 5.3 里那个丢字符问题chunk参数按目标控件的处理能力调现代浏览器里的输入框可以给 100老式 Win32 编辑框给 20 更稳。参数说明intervalMs是全局节奏40ms 是一个兼顾速度和稳定性的起点重试的退避倍数给 3 倍是为了给目标程序留出把队列排空的时间退避太短等于没退。验证环节不要靠肉眼看。文本类操作发完之后回读一次目标控件的内容做比对鼠标类操作发完之后用GetCursorPos读回实际坐标和预期坐标对比按键类操作可以在目标程序里挂一个轻量的键盘钩子记录实际收到的键序列。这套自检写起来二十分钟能省掉后面几十次「到底发出去没有」的猜谜。这些参数没有普适值。我现在的习惯是每接一个新目标程序先用一个最小脚本把间隔从 10ms 往上试记录第一次稳定不丢的数值再乘 2 作为正式参数——那次批量录入跑了两千条才发现最后三百条全是重复的就是因为间隔贴着临界值前面快后面慢从那以后每次定节奏我都强制走一遍加压测试。希望帮到你。本文还有配套的精品资源点击获取
