CancelIoEx取消控制台ReadKey/ReadLine时为何吞掉首次输入？

问题定性 #

该问题既不是纯粹的操作失误，也不是无法规避的Windows/.NET框架缺陷，本质是控制台异步IO取消机制与.NET Console封装层的缓存逻辑存在交互断层，导致的读取状态残留。

• CancelIoEx对控制台输入句柄的取消作用，仅为唤醒阻塞在ReadConsole/ReadFile调用上的线程，抛出IO终止错误，既不会自动清理控制台内核输入缓冲区的读写指针，也不会复位.NET层内置的输入内存缓存状态。
• 被强制取消的IO操作，在中断发生瞬间已经从内核缓冲区读取了部分待返回的输入数据，但这部分数据既没有被返回给上层的ReadKey/ReadLine调用，也没有被存入.NET的内部缓存供后续调用使用，成为悬空的残留数据，会直接“吞掉”后续正常读取流程遇到的第一个有效输入。
• 调整控制台窗口大小后行为恢复的现象，刚好可以验证这个机制：窗口尺寸变化会触发Windows控制台子系统的内部状态刷新，重置输入流的读写指针，刚好冲掉了之前残留的悬空读取状态。

复现现象匹配 #

• 原ReadKey复现场景中，被中断的第一次读取在取消瞬间已经捕获到用户后续按下的第一个按键（示例中的a键），但因为IO被打断，这个按键没有被返回给上层逻辑，导致第二次ReadKey调用只能捕获到用户第二次按下的b键，最终输出Keys: , B的结果。
• 替换为ReadLine的扩展复现场景中，被中断的读取已经从内核缓冲区取走了第二行输入的首个字符，导致后续正常读取时，拿到的字符串是从第二个字符开始的，出现Read: 234的异常结果，和实验观测完全吻合。

彻底终止底层读取需要的补充操作 #

仅调用CancelIoEx无法彻底终止底层控制台读取流程，必须在取消动作完成后主动完成两层状态重置，才能避免输入被吞的问题：

• 内核层状态重置：取消IO后立刻调用FlushConsoleInputBuffer清空整个控制台输入缓冲区，把所有残留的未处理输入、悬空的读取指针全部清掉。
• .NET封装层状态重置：
  • 对.NET 5+/Core版本：取消IO后主动释放静态的Console.In对象，触发输入流的重新初始化，清掉.NET层内存缓存里的无效指针。
  • 对.NET Framework版本：因为没有直接暴露输入流重置接口，在清空内核缓冲区后，通过SetConsoleMode临时切换一次控制台输入模式再切回原配置，触发.NET层重新探测控制台输入状态，顺带复位内部内存缓存。
• 注意：不要尝试用一次“空读取”消化残留输入，这种方式本质上还是把残留数据当成了用户输入，依然存在误吞有效输入的风险。

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