写这一篇的起因是我最近在做一个跨平台的自动化工具需要同时控制 Windows、macOS 和 Linux 下的鼠标键盘。折腾了一圈发现网上关于“模拟输入”的资料大多是零散的使用教程要么只讲某个库怎么调要么只讲 Windows 上的某一种方案。真正把底层原理、不同方式的区别、适用场景讲透的文章很少。所以我把这一路的调研和实践整理出来从消息层到驱动层从 Windows 到跨平台把“所有键盘鼠标模拟方式”这回事一次说清楚。这篇文章适合三类人一是刚开始接触 UI 自动化的新手想理解 PyAutoGUI、AutoHotkey 这类工具背后到底做了什么二是需要自研自动化工具的工程师正在纠结底层方案怎么选三是做外设开发或系统底层的朋友想了解不同层级的输入注入到底有什么差异。我会直接讲原理、讲实现也会讲清楚各种方案的坑。1. 输入模拟的整体分层与核心概念1.1 输入模拟到底在模拟什么要理解键盘鼠标模拟先搞清楚一个核心问题我们在模拟的到底是什么。操作系统层面的输入本质上就是一组带有特定参数的事件。键盘事件的核心参数是按键的虚拟键码Virtual-Key Code、扫描码Scan Code以及按下/抬起标志鼠标事件的核心参数是按键编号左键、右键、中键等、滚轮方向与步数、指针的绝对或相对位移。无论你用的是 Python 的pynput还是 C 里直接调 Windows API最终落到系统里的都是这些信息。// 键盘消息的 lParam 里携带了大量信息 // bit 0-15: 按键重复计数 // bit 16-23: 扫描码 // bit 24: 是否为扩展键如方向键、功能键 // bit 30: 前一个按键状态0按下1抬起 // bit 31: 转换状态0按下1抬起事件本身是统一的但“事件从哪个层级注入系统”却千差万别。这个层级决定了模拟的适用范围——是只发给某个窗口还是发给整个系统是能被普通程序接收还是需要管理员权限是能被反作弊系统识别还是能做到几乎和真实硬件一致。我把这些方案按层级从高到低排了一版层级典型方式作用范围权限要求典型应用消息层PostMessage / SendMessage仅单个窗口无UI 自动化测试API 层SendInput / keybd_event / mouse_event整个系统普通权限即可键鼠精灵、辅助工具驱动层过滤驱动 / 内核回调整个系统管理员/驱动签名录放工具、虚拟设备硬件层单片机/Arduino HID物理操作无硬件硬件外挂、测量设备层级越往下模拟的“真实度”越高系统越难分辨这是真实输入还是程序模拟。但相应的实现成本、权限要求、系统兼容性问题也越多。不少人只熟悉其中一层看到一个方案就到处用结果处处碰壁。接下来我按层级逐个拆解。1.2 输入事件进入系统的完整链路在展开各层级方案之前有必要把一次真实按键从物理到系统的完整链路讲清楚。我以 Windows 为例因为它的输入架构最典型理解了 Windows 再看其他系统都是触类旁通。物理按键按下后键盘控制器产生一个扫描码如0x1E代表 A 键按下0x9E代表 A 键抬起通过 USB 总线进入系统被键盘类驱动kbdhid.sys/i8042prt.sys接收。驱动把扫描码包装成一个KEYBOARD_INPUT_DATA结构上报到系统输入栈。经过win32k.sys的加工扫描码被转换成虚拟键码再包装成线程输入消息投递到当前焦点窗口所在线程的消息队列里。typedef struct _KEYBOARD_INPUT_DATA { USHORT UnitId; // 键盘实例编号 USHORT MakeCode; // 扫描码 USHORT Flags; // 按下还是抬起扩展键标志 USHORT Reserved; ULONG ExtraInformation; // 附加信息很多程序用它来识别输入来源 } KEYBOARD_INPUT_DATA;注意ExtraInformation这个字段它携带了额外信息不少安全软件就是通过向这个字段写入自定义标记来识别“这是不是我的驱动注入的输入”。同理鼠标事件经过MOUSE_INPUT_DATA结构上报包含坐标、按键状态、滚轮值等。不同层级的模拟其实就是在这条链路的不同位置“插入”伪造事件。消息层方案是在最末端——直接把消息丢进窗口线程队列API 层方案是在中游——从用户态调用系统服务让内核驱动层“代为上报”一次输入驱动层方案是在源头——直接构造KEYBOARD_INPUT_DATA结构上报。插入位置越靠上被识破的概率越大越靠下越接近真实输入。2. 消息层模拟最轻量但限制最多2.1 PostMessage 和 SendMessage 的本质区别消息层模拟在 Windows 上最常见的两个函数就是PostMessage和SendMessage。很多初学者分不清这俩实际用起来差别极大。PostMessage是异步投递。它把一条消息放进目标窗口所属线程的消息队列后立即返回不等待目标窗口处理。SendMessage是同步发送它会跨线程必要时跨进程直接把消息派发给目标窗口的窗口过程直到窗口过程处理完毕才返回。对于输入模拟来说这俩都有致命限制消息只是发给“某一个窗口”而不是发给系统。// 向指定窗口发送按下 A 键的键盘消息 [DllImport(user32.dll)] static extern bool PostMessage(IntPtr hWnd, uint Msg, IntPtr wParam, IntPtr lParam); uint WM_KEYDOWN 0x0100; uint WM_KEYUP 0x0101; // wParam 是虚拟键码这里 0x41 是 A 键 PostMessage(targetWindowHandle, WM_KEYDOWN, (IntPtr)0x41, (IntPtr)0x001E0001); PostMessage(targetWindowHandle, WM_KEYUP, (IntPtr)0x41, (IntPtr)0xC01E0001);这种方式能生效的场景非常窄目标窗口必须允许在后台接收键盘消息而且它对输入的处理逻辑必须基于WM_KEYDOWN/WM_KEYUP消息本身。像 Notepad、老式 Win32 文本框这类控件是可以的但很多现代 UI 框架比如基于 Chromium 的界面、部分游戏引擎会直接读取 Raw Input原始输入或 DirectInput 状态根本不走窗口消息这种情况 PostMessage 就是白费劲。2.2 消息层方案的适用场景与局限我在自动化测试项目里用消息层方案比较多但前提是目标程序必须配合。比如你写了一个 Windows 桌面应用要测试它的快捷键是否生效用 PostMessage 直接投递WM_HOTKEY或WM_KEYDOWN消息是最高效的。不需要焦点、不占鼠标键盘测试可以并行跑多个实例。局限也同样明显。第一它产生不了全局输入状态——GetKeyState/GetAsyncKeyState查询不到你模拟的按键状态。第二部分游戏和图形应用有一套独立的输入轮询路径PostMessage 对它们完全无效。第三消息层模拟并没有真的把事件交给系统输入队列所以它也模拟不出真实按键那种“所有窗口都能感知”的效果。注意如果目标程序用GetAsyncKeyState轮询按键状态PostMessage 方案直接失效。你需要切换到 API 层方案SendInput因为只有走系统输入队列的模拟才能真正改变按键状态。所以我的结论是消息层方案只适合“自家人测试自家人”不适合做通用型的模拟输入工具。新手容易走入的误区是拿 PostMessage 去模拟游戏输入结果发现毫无反应其实是层次搞错了。3. API 层模拟应用层最正统的方案3.1 SendInput 原理详解如果说消息层是在“收件箱”里造假信那 SendInput 就是在“邮局”里直接塞信——它把输入事件交到系统输入队列由系统内核统一分发。这是 Windows 应用层模拟输入的“正统方案”也是我日常最常用的一招。SendInput接收一个INPUT结构数组可以一次批量发送多个输入事件[StructLayout(LayoutKind.Sequential)] public struct INPUT { public uint type; // 1键盘, 0鼠标 public InputUnion U; // 联合体键盘输入或鼠标输入的具体参数 } [StructLayout(LayoutKind.Explicit)] public struct InputUnion { [FieldOffset(0)] public KEYBDINPUT ki; [FieldOffset(0)] public MOUSEINPUT mi; [FieldOffset(0)] public HARDWAREINPUT hi; }它的处理流程我画在脑子里是这样的应用调用SendInput后参数被传到win32k!NtUserSendInput内核函数系统会把KEYBDINPUT/MOUSEINPUT结构转换成内部统一的输入数据结构然后把这个输入“注入”到原始输入流里。关键点是这条路径上有多个钩子可以拦截和标记SetWindowsHookEx的钩子比如WH_KEYBOARD_LL低级键盘钩子能看到这些事件安全软件也能通过 Callback 回调感知这些事件。所以 SendInput 并不是“无痕”的普通程序看不到差别但专门做反作弊的程序识别它并不难。关于KEYBDINPUT里的参数很多人只填虚拟键码就完事。但如果目标程序要做按键映射比如把某几个按键重映射成其他功能它在读取扫描码而不是虚拟键码时你的模拟就会失效。正确姿势是同时填充wVk和wScanpublic struct KEYBDINPUT { public ushort wVk; // 虚拟键码可填 0表示不指定 public ushort wScan; // 扫描码可填 0表示不指定 public uint dwFlags; // KEYEVENTF_EXTENDEDKEY, KEYEVENTF_KEYUP, KEYEVENTF_UNICODE 等 public uint time; // 时间戳填 0 表示系统自动 public IntPtr dwExtraInfo;// 附加信息 }当dwFlags设置了KEYEVENTF_UNICODE时wScan直接携带 Unicode 字符编码可用来输入任意 UTF-16 字符。这个技巧在处理中文、日文、特殊符号时非常好用能绕过输入法状态导致的乱码问题。3.2 keybd_event 和 mouse_event 的迁移老一代程序员都用过keybd_event和mouse_event现在的 SDK 文档明确建议新代码改用SendInput原因很简单keybd_event本质上就是SendInput的一个薄封装但它一次只能发一个事件而SendInput支持批量发送性能和对齐性更好。// 旧式写法keybd_event keybd_event(A, 0, 0, 0); // 按下 A keybd_event(A, 0, KEYEVENTF_KEYUP, 0); // 抬起 A // 新式写法SendInput INPUT inputs[2] {}; inputs[0].type INPUT_KEYBOARD; inputs[0].ki.wVk A; inputs[1].type INPUT_KEYBOARD; inputs[1].ki.wVk A; inputs[1].ki.dwFlags KEYEVENTF_KEYUP; SendInput(2, inputs, sizeof(INPUT));mouse_event对应的是MOUSEINPUT结构关键点在于坐标的表示方式。MOUSEINPUT支持两种坐标绝对坐标设置MOUSEEVENTF_ABSOLUTE和相对坐标不设置该标志。绝对坐标有个坑它的值域不是屏幕像素而是 0 到 65535 的标准化坐标。要从屏幕像素转换到标准化坐标公式是X_norm X_pixel * 65536 / 屏幕宽度 1 Y_norm Y_pixel * 65536 / 屏幕高度 1这个公式我在项目里写了无数遍忍不住多说一句为什么要 1因为极左/极右坐标在部分多屏环境下会被系统当作无效坐标丢弃加 1 是微软文档里推荐的稳健做法。3.3 用 C# 封装一个完整的输入模拟工具类我平时写 C# 比较多这里给一个我反复打磨的封装可以直接抄作业。里面包含了键盘按键、字符输入、鼠标移动和鼠标点击以及模拟滚轮。public static class NativeInputHelper { [DllImport(user32.dll, SetLastError true)] private static extern uint SendInput(uint nInputs, INPUT[] pInputs, int cbSize); // 省略 INPUT / KEYBDINPUT / MOUSEINPUT 结构定义见上文 public static void KeyPress(ushort vk) { INPUT[] inputs new INPUT[2]; inputs[0].type 1; inputs[0].U.ki.wVk vk; inputs[1].type 1; inputs[1].U.ki.wVk vk; inputs[1].U.ki.dwFlags 0x0002; // KEYEVENTF_KEYUP SendInput(2, inputs, Marshal.SizeOf(typeof(INPUT))); } public static void TypeText(string text) { INPUT[] inputs new INPUT[text.Length * 2]; int index 0; foreach (char c in text) { // 按下 inputs[index].type 1; inputs[index].U.ki.wVk 0; inputs[index].U.ki.wScan c; inputs[index].U.ki.dwFlags 0x0004; // KEYEVENTF_UNICODE index; // 抬起 inputs[index].type 1; inputs[index].U.ki.wVk 0; inputs[index].U.ki.wScan c; inputs[index].U.ki.dwFlags 0x0004 | 0x0002; // UNICODE | KEYUP index; } SendInput((uint)inputs.Length, inputs, Marshal.SizeOf(typeof(INPUT))); } public static void MouseClick(int x, int y, bool left true) { int screenWidth System.Windows.Forms.Screen.PrimaryScreen.Bounds.Width; int screenHeight System.Windows.Forms.Screen.PrimaryScreen.Bounds.Height; INPUT input new INPUT(); input.type 0; // 鼠标 input.U.mi.dwFlags 0x8000 | 0x0001; // ABSOLUTE | MOVE input.U.mi.dx (x * 65536 / screenWidth) 1; input.U.mi.dy (y * 65536 / screenHeight) 1; SendInput(1, new[] { input }, Marshal.SizeOf(typeof(INPUT))); // 按下再抬起 INPUT down new INPUT(); down.type 0; down.U.mi.dwFlags left ? 0x0002 : 0x0004; // LEFTDOWN / RIGHTDOWN SendInput(1, new[] { down }, Marshal.SizeOf(typeof(INPUT))); INPUT up new INPUT(); up.type 0; up.U.mi.dwFlags left ? 0x0004 : 0x0008; // LEFTUP / RIGHTUP SendInput(1, new[] { up }, Marshal.SizeOf(typeof(INPUT))); } }这个类我在多个自动化项目里用过支持批量键盘输入、Unicode 字符直输、鼠标绝对定位点击基本的录放功能都能覆盖。如果你想模拟组合键比如 CtrlC把按键按顺序放进一个INPUT数组里一并发送即可。4. 驱动层与硬件层模拟更高真实度的选择4.1 驱动级方案的典型结构与实现思路当 SendInput 不够用时比如你要做一个后台静默的录放工具、一个不干扰用户正常操作的自动化程序就需要往更低层走。常见方案是写一个键盘过滤驱动在驱动层把伪造的KEYBOARD_INPUT_DATA结构直接上报到系统输入栈。从实现角度说过滤驱动挂在kbdclass或i8042prt之上拦截 IRP 完成例程在设备扩展里维护一份输入队列。当用户态程序通过 DeviceIoControl 下发模拟指令时驱动把指令转换成KEYBOARD_INPUT_DATA数组再调用KeyboardClassServiceCallback这是kbdclass导出的回调函数直接把数据作为“物理输入”广播出去。typedef VOID (*PSERVICE_CALLBACK_ROUTINE)( PDEVICE_OBJECT DeviceObject, PKEYBOARD_INPUT_DATA InputDataStart, PKEYBOARD_INPUT_DATA InputDataEnd, PULONG InputDataConsumed );驱动方案的优势非常显著模拟出的输入几乎等同于真实物理设备上报连底层的扫描码时序都能模拟普通系统钩子、安全软件的低层监控很难区分。但代价也大驱动需要签名Windows 10/11 强制要求内核驱动签名否则无法加载开发过程中蓝屏风险不可忽视每次系统更新都可能引入兼容性问题。我个人的建议是除非业务确有必要否则别轻易上驱动方案。很多场景用 SendInput 就够了驱动项目从开发到稳定周期往往按大版本系统迭代来计算。4.2 硬件模拟用单片机模拟真实的键鼠还有一种方案绕开操作系统权限限制——直接用单片机模拟出一个 USB HID 键盘/鼠标。这就是市面上很多“硬件级键鼠模拟器”的原理也是最强硬的模拟方式。拿 Arduino Leonardo或 ATmega32U4 主控举例它内置 USB HID 功能可以直接被系统识别为键盘和鼠标。用Keyboard.h和Mouse.h库就能控制#include Keyboard.h #include Mouse.h void setup() { Keyboard.begin(); Mouse.begin(); } void loop() { // 模拟 CtrlC Keyboard.press(KEY_LEFT_CTRL); Keyboard.press(c); delay(50); Keyboard.releaseAll(); // 模拟鼠标移动到绝对坐标 Mouse.move(100, 50, 0); delay(1000); }硬件模拟的原理是让单片机芯片直接和主机通信操作系统看到的就是一个 USB 键盘/鼠标的报告。这种方式对于操作系统来说没有任何“程序注入”的痕迹因为确实就是硬件在发信号。它的掉电可重刷、免驱动、跨系统通用适合做演示控制器、无障碍辅助设备、产线自动化测试等场景。但硬件模拟有它自己的短板通信延迟更高USB Polling Interval 通常 1ms 到 8ms不能像软件方案那样一次性读取屏幕像素来“智能决策”需要和上位机软件配合才能实现完整的自动化逻辑。而且如果要做成产品PCB 设计、固件升级、USB 协议兼容性这些都是工作量。5. 跨平台方案对比macOS、Linux 与 Windows5.1 macOS 的 CGEvent 与辅助功能权限macOS 的输入模拟主要依赖 Quartz Event ServicesCGEvent系列函数。核心函数是CGEventPost它可以把构造好的事件投递到系统事件流里。// 模拟鼠标点击 CGPoint point CGPointMake(100, 200); CGEventRef move CGEventCreateMouseEvent(NULL, kCGEventMouseMoved, point, kCGMouseButtonLeft); CGEventPost(kCGHIDEventTap, move); CGEventRef down CGEventCreateMouseEvent(NULL, kCGEventLeftMouseDown, point, kCGMouseButtonLeft); CGEventPost(kCGHIDEventTap, down); CGEventRef up CGEventCreateMouseEvent(NULL, kCGEventLeftMouseUp, point, kCGMouseButtonLeft); CGEventPost(kCGHIDEventTap, up);macOS 这里有个绕不开的权限门槛任何进程要使用CGEventPost模拟输入都必须先在“系统设置 → 隐私与安全性 → 辅助功能”里获得授权否则事件会被静默丢弃而且 API 不会给你任何错误提示。我第一次踩这个坑时排查了半天后来才发现是权限没有打开。开发调试时建议先去系统设置确认你的终端/IDE 已经被加入了辅助功能列表。macOS 还有一种底层方案IOHIDManager 虚拟 HID 设备允许在用户态注册一个虚拟键盘/鼠标设备。这是 macOS 上最接近“硬件级”的方案但同样需要辅助功能权限而且 API 使用方式比 CGEvent 复杂得多文档也比较少实际开发成本不低。5.2 Linux 的 uinput 与 X11/Xorg 方案Linux 的输入模拟有两条主流路径。一条是在图形环境X11下用XTest扩展通过XTestFakeKeyEvent/XTestFakeMotionEvent伪造输入事件。它走的是 X Server 的输入扩展优点是用起来简单几乎所有 X11 环境都支持。缺点是现在很多新环境默认跑 WaylandXTest 在 Wayland 下基本不可用。// X11 下模拟一个按键 #include X11/extensions/XTest.h Display *display XOpenDisplay(NULL); // 这里 49 是 X11 的 keycode对应键盘上的 A 键 XTestFakeKeyEvent(display, 49, True, CurrentTime); // 按下 XTestFakeKeyEvent(display, 49, False, CurrentTime); // 抬起 XFlush(display); XCloseDisplay(display);另一条是走内核的uinput虚拟输入子系统。uinput允许用户态程序创建一个虚拟输入设备然后通过写入事件模拟按键、触摸、滚轮、摇杆等一切输入。这种方式不依赖图形环境在 Wayland 和纯命令行环境都能用而且因为是内核级输入权限要求高——通常需要 root 或uinput设备节点有合适的权限。// 通过 uinput 模拟一个按键事件 #include linux/uinput.h int fd open(/dev/uinput, O_WRONLY | O_NONBLOCK); // 配置设备能力创建虚拟键盘 // ... 这里省略初始化代码 struct input_event ev; memset(ev, 0, sizeof(ev)); ev.type EV_KEY; ev.code KEY_A; // 按键 A ev.value 1; // 按下 write(fd, ev, sizeof(ev)); ev.value 0; // 抬起 write(fd, ev, sizeof(ev));使用uinput时还需要配置 udev 规则让当前用户拥有/dev/uinput的访问权限。不配置的话一般用户会收到Permission denied错误。5.3 常用跨平台封装库的底层映射关系很多人喜欢用跨平台库省心省力。我把常见的几个库和它的底层实现映射关系整理了一下库底层实现专注平台典型场景PyAutoGUIWindows: SendInput / macOS: CGEvent / Linux: XTest全平台快速脚本、教学演示pynputWindows: SendInput / macOS: CGEvent IOHID / Linux: XTest uinput全平台Python 自动化AutoHotkey组合了 SendInput、PostMessage、驱动注入WindowsGUI 自动操作、热键映射RobotJSmacOS: CGEvent / Linux: XTest / Windows: SendInput全平台Node.js 自动化这里要提醒一下封装库方便是真方便但如果你要做的项目对低延迟、高自由度有要求建议还是直接封装底层 API。封装库为了通用性往往牺牲了一些底层能力。比如有些库不支持批量发送消息导致快速按键时时序不可控有些库在高频鼠标移动时性能不足。在需要精细控制的场景里手写底层代码反而更简单。6. 四种方案的选型决策与真实项目踩坑记录6.1 方案选型决策表什么场景选什么方案把几种方案的特点总结成一张决策表遇到项目时直接对着表格选型比拍脑袋靠谱。判断维度消息层API 层驱动层硬件层开发成本低低很高中高真实度低中高最高是否影响焦点否是需要前台否否权限要求无普通权限管理员签名无典型项目单元测试录放工具、办公自动化后台静默自动化产线测试、辅助设备推荐程度一般首选谨慎特殊场景拿一个实际例子说说我之前做一个客服系统自动录入工具要求在业务员操作其他软件的同时自动把客户信息填到另一个窗口里。这个场景如果用 SendInput焦点会被抢走业务员就没法同时做别的事用 PostMessage 则目标窗口不一定支持。最后硬着头皮写了驱动方案在驱动层注入输入事件才做到“双开”同时操作。反过来如果你只是做一个后台自动点击脚本完全不干扰用户其实用 SendInput 就够了——不需要焦点或者用SetForegroundWindow抢一下焦点即可没必要上驱动。6.2 Windows 输入模拟的几大坑下面这几个坑我基本都踩过列出来给你当避雷指南。第一UIPI 权限隔离问题。从普通权限进程向管理员权限进程发送模拟输入会被系统直接拦截。现象是 SendInput 返回成功返回值大于 0但目标程序毫无反应。解决思路是通过任务计划程序启动一个高权限代理进程由它来执行输入注入。第二中文输入法导致的乱码问题。用 SendInput 发送字母键时如果当前输入法是中文状态输入到文本框里的可能是拼音字母或汉字候选。解决办法就是用上文提到的KEYEVENTF_UNICODE直接发送 Unicode 字符绕开输入法状态。第三DPI 缩放导致的坐标偏移。在 Windows 高分屏下如果你的进程没有声明 DPI 感知系统会自动把坐标缩放一次结果就是你传入的 (1920, 1080) 实际落在屏幕中间而不是右下角。解决方式是在程序启动时调用SetProcessDPIAware()或在 manifest 里声明 DPI 感知。第四SetLastError 没有正确捕获。SendInput在调用失败时并不总是设置 LastError新手排查问题经常一头雾水。稳妥做法是同时检查返回值返回 0 表示一个都没发送成功和Marshal.GetLastWin32Error()。6.3 延迟与稳定性问题排查模拟输入最常见的两个问题一是有延迟二是不稳定。延迟问题多半出在消息队列阻塞或线程优先级上。SendInput 是同步注入但它进入系统输入队列后是异步分发的如果目标程序的 UI 线程卡死输入就会排队。排查方法是先确认目标窗口是否“无响应”再看自己的发送线程是否被高负载任务拖慢。高频输入的场景建议用单独的高优先级线程来发送输入事件。不稳定问题通常和焦点变化有关。SendInput 依赖当前焦点窗口——它会把你的事件投递到焦点窗口。如果在这个过程中另一个窗口抢了焦点你的输入就飞了。解决思路是在自动化开始前用SetForegroundWindow锁定目标窗口并且在发送过程中GetForegroundWindow校验发现焦点丢失就停顿重试。注意SetForegroundWindow在某些 Windows 版本和某些窗口上会失败。一个比较有效的替代方案是模拟 Alt 键按下再释放来绕过前台锁或者用AttachThreadInput把当前线程输入队列和目标窗口线程关联强行置前。6.4 把键盘钩子用于输入拦截的注意事项和模拟输入相关的另一个能力是“拦截输入”——也就是钩子。Windows 的SetWindowsHookEx可以安装低级键盘钩子WH_KEYBOARD_LL许多自动化软件用这个能力来监听全局按键。比如我写热键工具时会注册一个全局热键就是用低级钩子实现的。低级钩子和 SendInput 的配合有条经验在钩子回调里返回非零值可以吞掉按键事件但如果你同时又要模拟相同的按键要小心勾子先于 SendInput 返回导致你模拟的事件也被钩子吞掉。还有低级钩子的回调是随系统消息一起调度的回调里千万别做耗时操作否则整个输入系统都会变卡。跨线程调用时记得用Invoke把逻辑切回专用线程。7. 实测案例从 0 到 1 实现一个通用键鼠录放工具理论讲完用完整案例收个尾——写一个最简可用的键鼠录放工具。这个工具的思路很直接一段录制脚本里记录真实的输入事件然后循环播放。7.1 录制模块使用低级钩子捕获输入事件录制需要两个低级钩子WH_KEYBOARD_LL和WH_MOUSE_LL。在钩子回调里把自己关心的事件结构保存进队列。低级钩子的回调函数签名是统一的拿到KBDLLHOOKSTRUCT或MSLLHOOKSTRUCT就能获取完整的按键状态和鼠标坐标。private static IntPtr LowLevelKeyboardProc(int nCode, IntPtr wParam, IntPtr lParam) { if (nCode 0) { KBDLLHOOKSTRUCT hook (KBDLLHOOKSTRUCT)Marshal.PtrToStructure(lParam, typeof(KBDLLHOOKSTRUCT)); int msg (int)wParam; // WM_KEYDOWN / WM_KEYUP / WM_SYSKEYDOWN / WM_SYSKEYUP if (msg WM_KEYDOWN || msg WM_KEYUP) { Record(new KeyboardEvent { VkCode hook.vkCode, ScanCode hook.scanCode, IsKeyUp (msg WM_KEYUP), Timestamp GetTimestampMilliseconds() }); } } return CallNextHookEx(_hookID, nCode, wParam, lParam); }这里细节很多。首先要记录时间戳并且建议用Environment.TickCount或单调时钟而不是DateTime.Now——系统时间被改会导致回放时序错乱。其次要区分扩展键方向键、小键盘等扩展键的标志位在flags LLKHF_EXTENDED回放时需要设置KEYEVENTF_EXTENDEDKEY否则个别键按下位置不对。7.2 回放模块多线程时间线调度回放的核心是把录制的事件按原有时序重放。最简单的方式是建一个后台线程按顺序读取事件列表根据事件的时间差去Thread.Sleep。public void Playback(ListInputEvent events) { long start GetTimestampMilliseconds(); long baseTime events[0].Timestamp; for (int i 0; i events.Count; i) { // 按照与第一个事件的时间差来等待 long expectedDelay events[i].Timestamp - baseTime; long actualElapsed GetTimestampMilliseconds() - start; if (expectedDelay actualElapsed) { Thread.Sleep((int)(expectedDelay - actualElapsed)); } // 发送事件 SendSingleEvent(events[i]); } }这个调度器有个稳定的关键点不要把Thread.Sleep精度作为时序基准。Sleep(50) 实际可能睡 60-70 毫秒累积误差会让播放越来越偏。所以要用expectedDelay - actualElapsed的动态差值来校准让每次等待时间自我修正。.NET 的Thread.Sleep精度大约 15ms对普通自动操作够用如果你要做亚毫秒级精度的播放建议改用WaitableTimer或多媒体定时器。7.3 录放工具完整链路调试记录我在实现完后跑了几轮冒烟测试发现两个典型问题在这里如实记录。第一个问题是鼠标位置的偏移。简单录制的鼠标事件如果使用绝对坐标一旦目标窗口位置变化或分辨率改变回放就会“点错地方”。解决方向是录制时记录鼠标相对目标窗口客户区的位置clientPoint Cursor.Position - GetWindowClientOrigin(hwnd)回放时再加上当前窗口的新位置。这样一个窗口被拖走了只要重新定位窗口脚本还能正确点击。第二个问题是录制时无意间把钩子实例自身触发的注入事件也录进去了。也就是说你播放一次脚本这个播放行为本身又会被低级钩子监听到从而把播放过程又记录一遍。我在录制模块里加了一个“是否处于播放状态”的静态标志播放前置位播放后复位录制回调里直接跳过标志为真的时间段。这个陷阱不提前处理录放工具就会变成“自我复读机”越放越长。这个录放工具放到真实场景里比如做软件演示的自动化操作、验收测试里的重复性回归完全够用。综合起来看键鼠模拟的技术栈其实不复杂关键是要选对层级、处理好边界情况。我自己在反复折腾这些方案后最大的体会是不要一开始就追求最底层的方案。能用 API 层解决的就用 API 层把消息层、API 层的边界和限制吃透大部分自动化需求都能搞定。真遇到性能、真实度、后台静默这些硬需求再往驱动层和硬件层走也不迟。最后分享一个小技巧在 Windows 上排查输入模拟问题时先开一个“记事本”窗口做最基础的打点测试再逐层排查焦点、权限、DPI、输入法这些变量比直接在目标程序里调试高效得多。这套方法论放到 macOS 和 Linux 上也同样适用。