芙蓉塘外有轻雷1. 输入处理的第一性问题：为什么通用应用的写法在游戏里会翻车
Windows 处理键盘鼠标的标准链路，我想每个写过 Win32 程序的开发者都门儿清：硬件产生中断，驱动把数据送进系统输入队列，应用通过消息循环拿到 WM_KEYDOWN、WM_MOUSEMOVE，然后在窗口过程里响应。这套机制对于记事本、浏览器、办公软件完全够用，因为人的输入频率远远低于系统处理消息的速度，队列永远不会积压。
但游戏不一样。游戏对输入的实时性要求极高，而且输入源全部集中在玩家的手和鼠标上，一秒钟可能产生几十上百次有效操作。当你按下 W 键时，期望的是下一帧角色就要动，而不是等消息排队轮到这一条再动。Windows 的消息队列本质上是 FIFO 缓冲，消息从产生到被应用读取，中间存在不可控的延迟。
我当年第一次做动作游戏原型的时候，用的就是最常规的 WM_KEYDOWN 处理移动。程序跑起来，窗口里的小方块动倒是能动，但手感始终有一种"肉肉"的迟钝感，尤其是在帧率波动的时候——帧率一掉到 40 以下，操作延迟就变得非常明显。后来我看到一份老外的 GDC 演讲材料，里面提到一个关键概念：游戏输入必须是"每帧采样"而非"逐条响应"。
这个思路转变至关重要。消息模型是事件驱动的，一条消息来一次处理；而游戏循环模型是状态驱动的，每一帧去问"此刻所有输入设备处于什么状态"，然后据此更新游戏世界。二者最大的差别在于：消息模型天然是异步的、有缓冲的，而状态模型是同步的、确定性的。
具体到代码层面，游戏循环里处理输入通常有两种做法。第一种是用 GetAsyncKeyState 这类函数直接读按键状态——它不受消息队列缓冲影响，返回的是物理键盘硬件的实时状态位。第二种是使用专用输入 API（Raw Input、XInput），由系统直接提供低延迟的输入数据。无论哪种，核心原则都是"每帧开始时采样一次，然后整个逻辑层共享这份快照"。
不过这里有个容易被忽略的坑：GetAsyncKeyState 虽然读的是实时状态，但它跳过了消息系统的规范化处理。举个例子，GetAsyncKeyState 不会自动处理按键 auto-repeat，你按住 W 键不放，它返回的始终是"按下"状态，而不会像 WM_KEYDOWN 那样反复触发。这对移动操作来说是好事——按住即持续移动，不用自己去抖。但副作用是，如果你依赖 WM_KEYDOWN 做菜单导航这类"一次按键一次触发"的逻辑，就得自己实现下降沿检测：记录上一帧状态，当前帧按下且上一帧未按下，才算一次有效触发。这个"上升沿/下降沿"的判断逻辑算是游戏输入处理的第一道基本功，后面讲输入架构时我还会再展开。
说回到消息机制。游戏里 窗口过程仍然不能放弃，但它的职责要收敛——负责处理窗口尺寸变化、焦点切换、DPI 变化这类系统级事件，而键盘鼠标的实时交互数据则全部通过更底层的 API 获取。这是输入处理的大方向，也是在动手写代码之前必须先想清楚的架构决策。很多新手游戏开发者一开始就把 WM_KEYDOWN 当成唯一输入来源，后面想优化延迟时才发现整条链路都是队列缓冲的，只能推倒重来。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 三大输入 API 的生态位：DirectInput、XInput 与 Raw Input
Windows 游戏开发走到今天，输入领域的 API 呈现出一种"老中青三代共存"的格局，这不是历史包袱，而是每一代 API 都有自己的不可替代之处。搞懂这三个 API 各自的生态位，比盲目选某个 API 往代码里怼要重要得多。
2.1 DirectInput：年迈但仍在某些角落守着经典设备
DirectInput 是 DirectX 时代早期的产物，最初设计目标是提供对键盘、鼠标、游戏手柄的统一访问，尤其是号称能"绕过系统消息链路的直接访问"。微软当年的拳头功能是力反馈（Force Feedback），可以通过操纵杆和专用方向盘输出震动效果，这在模拟飞行和赛车游戏里非常吃香，直到今天，某些带有力反馈功能的飞行摇杆仍然首选 DirectInput 接口。
但 DirectInput 有两个为人诟病的问题。其一，它的鼠标数据默认是相对移动量（delta），和系统鼠标的绝对定位模式有区别，很多开发新手在这里栽过跟头——DirectInput 给的鼠标 dx/dy 值在某些驱动程序下不稳定，时快时慢。其二，DirectInput 拿到的鼠标数据是经过系统"鼠标加速度"设置的平滑化处理过的，这对于追求像素级精准的射击游戏来说完全是灾难。正因为这些原因，DirectInput 在键盘鼠标领域的实际使用率越来越低，主流引擎也都不再用它处理键鼠输入。
我的建议是：除非你要做的是模拟飞行摇杆、方向盘这类外设的力反馈，否则 键盘和鼠标就不要再写 DirectInput 代码了，改用 Raw Input。
2.2 XInput：Xbox 手柄在 Windows 上的第一公民
XInput 是微软为 Xbox 360 引入的手柄输入 API，后来成为整个 Xbox 生态系在 Windows 上输入的标准接口。它的定位极其清晰：只服务 Xbox 系手柄，换来的是极简的 API 和极稳定的表现。
为什么说极简？XInput 把整个手柄抽象成一个 XINPUT_STATE 结构体，里面有四个部分：按键位掩码、左摇杆的 x/y 值、右摇杆的 x/y 值、两个扳机键的模拟量。你只需要 XInputGetState 这一个函数，就能拿到手柄当前帧的完整状态。没有复杂的配置过程，不需要手动枚举设备，即插即用，Windows 系统已经替你完成了绝大多数驱动和兼容性工作。
XInput 这套 API 为手柄热插拔做了很优雅的设计。XInputGetState 返回 ERROR_DEVICE_NOT_CONNECTED 就代表手柄掉线或者没插，你只需要轮询这个返回码，就能干净地处理手柄拔插事件。我用 XI