为何Console.KeyAvailable为true后，Console.ReadKey可读取按键？

嘿，这个问题问得特别到位——很多刚接触.NET控制台输入的开发者都会被这个组合的逻辑搞懵，我来给你拆解清楚底层到底在干嘛：

核心在于系统维护的控制台输入缓冲区，以及这两个方法完全不同的职责：

• Console.KeyAvailable：这是个非阻塞的检查操作。它会立刻查询系统的控制台输入缓冲区，看看有没有已经等待处理的按键数据——有就返回true，没有就马上返回false，全程不会让你的程序停下来等用户输入。
• Console.ReadKey()：它的“阻塞”是有前提的——只有当输入缓冲区是空的时候，它才会挂起当前线程，等待用户按下按键。如果缓冲区里已经有数据（也就是KeyAvailable刚返回true的时候），它会直接从缓冲区里取出最靠前的那条按键记录，立刻返回结果，根本不会等待。

底层运作的完整流程： #

操作系统的控制台子系统会负责监听硬件的按键事件，当用户按下或松开按键时，系统会把对应的按键信息（比如键的编码、是否按住Shift/Ctrl等修饰键）打包成输入记录，放进控制台的输入缓冲区里。

你的循环代码其实是在做“轮询检查”：

1. 进入while(true)循环，先调用KeyAvailable查看缓冲区有没有数据；
2. 如果返回true，说明缓冲区里已经躺着用户之前按下的按键数据，这时候调用ReadKey()会直接取走这条数据，完全不会阻塞；
3. 如果返回false，就跳过ReadKey()，继续下一轮循环，直到下一次检查到缓冲区有新的按键数据。

举个直观的例子：当你按下A键，系统立刻把A的按键记录放进缓冲区。下一次你的循环执行KeyAvailable时，发现缓冲区非空，就会调用ReadKey()——这时候ReadKey()直接从缓冲区拿数据，瞬间完成，完全不会卡着等你再输入。只有当缓冲区空的时候，ReadKey()才会等着用户按键。

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