Windows键盘布局切换：与字符输入多阶段处理的同步问题

在探索处理用户键盘布局切换的最稳健方案时，核心困惑在于WM_INPUTLANGCHANGE消息与键盘输入各处理环节的同步矛盾——键盘事件从硬件触发到窗口过程处理的多阶段流程中，各阶段依赖的键盘布局可能因切换操作出现不一致，再加上WM_INPUTLANGCHANGE的异步特性，进一步拉高了复杂度。

键盘事件处理的核心阶段与布局依赖边界 #

键盘事件从按下到被应用处理需经历三个关键阶段，每个阶段都可能形成独立的布局处理边界：

• 键盘驱动与系统队列阶段：按键事件由键盘驱动处理后进入系统队列，扫描码转虚拟码的操作在此阶段完成，且严格依赖当前键盘布局。若此时用户触发布局切换，队列中会同时存在用新旧布局生成的虚拟码消息。
• 消息泵与TranslateMessage阶段：消息泵从系统队列提取消息后，通常会调用TranslateMessage，后者内部通过ToUnicodeEx完成虚拟码到Unicode字符的转换，这一步同样依赖当前布局。由于该阶段与驱动阶段存在明显时间差，布局切换可能导致同一批队列消息在两个阶段使用不同布局处理，形成不一致的转换结果。
• 窗口过程处理阶段：消息到达窗口过程后，若窗口逻辑直接或间接调用依赖当前键盘布局的函数（如获取输入法状态），此阶段的布局状态又可能与前两个阶段不同，形成第三个处理边界。

WM_INPUTLANGCHANGE的异步特性带来的额外问题 #

WM_INPUTLANGCHANGE是异步发送到窗口过程的，它的到达时机是独立的第四个边界，理论上和前三个阶段的布局切换边界没有固定关联：可能在队列消息处理前、处理中或处理后到达，导致窗口无法准确判断当前生效的布局状态与已处理消息的匹配性。

实际可能出现的冲突场景 #

并非所有理论上的复杂情况都会实际发生，但以下场景是需要重点防范的：

• 布局切换发生在驱动处理部分消息后、剩余消息处理前，导致队列中混合新旧布局的虚拟码消息。
• TranslateMessage处理队列消息时，布局已切换，导致同一批虚拟码用新布局转换为字符，与驱动阶段的虚拟码逻辑冲突。
• WM_INPUTLANGCHANGE晚于部分已处理的键盘消息到达窗口过程，导致窗口误以为布局尚未切换，处理后续逻辑时出错。

降低复杂度的稳健处理逻辑 #

通过统一布局状态管理和消息处理逻辑，可以有效规避大部分同步问题：

• 维护窗口级别的布局状态变量：在窗口过程中维护一个当前生效的键盘布局变量，仅在收到WM_INPUTLANGCHANGE时更新该变量，后续所有依赖布局的操作（包括自定义字符转换、输入逻辑）都使用这个变量，而非实时调用GetKeyboardLayout。
• 清理待处理的键盘消息：当收到WM_INPUTLANGCHANGE时，清空当前窗口消息队列中未处理的键盘相关消息（WM_KEYDOWN、WM_KEYUP、WM_CHAR等），避免混合新旧布局的消息被处理。注意需过滤掉非键盘类消息，防止误删用户的其他操作指令。
• 自定义字符转换逻辑：不依赖TranslateMessage的默认转换，而是在窗口过程收到WM_KEYDOWN时，手动使用维护的当前布局变量调用ToUnicodeEx进行转换，确保转换逻辑与当前生效布局完全同步。
• 同步触发布局切换消息：如果是应用自身触发的布局切换，使用SendMessage而非PostMessage发送WM_INPUTLANGCHANGE，确保布局状态更新后再处理后续消息。

内容的提问来源于stack exchange，提问作者Ilya Zakharevich