Console.ReadLine() 并非卡住，而是严格等待 Enter 键输入换行符才返回；常见于未回车即结束输入、重定向文件末尾缺换行符等情况。
Console.ReadLine() 为什么有时“卡住”不返回？
它不是卡住，而是严格等待用户按下 Enter 才结束阻塞。只要输入缓冲区里没换行符（\n 或 \r\n），Console.ReadLine() 就一直挂起线程。常见于：用户只按了 Ctrl+Z（Windows）或 Ctrl+D（Linux/macOS）但没回车；或在重定向输入时，文件末尾缺换行符。
实操建议：
- 调试时别只输内容就点运行，务必敲
Enter - 若需读取不带换行的原始输入（比如密码、单字符操作），改用
Console.Read()或Console.ReadKey(true) - 在管道或文件重定向场景下（如
dotnet run ），确保 <code>input.txt最后一行有换行符
Console.Read() 和 Console.ReadKey() 的本质区别
Console.Read() 从输入流读取**下一个 Unicode 字符**（int），返回其 UTF-16 码点，遇到 EOF 返回 -1；它仍依赖底层流的缓冲行为，但不自动跳过空白或等待换行。
Console.ReadKey(true) 则绕过输入缓冲区，直接捕获键盘事件（Windows 下走 ReadConsoleInputW，Unix 下设终端为 raw 模式），立即返回按键信息，且可选是否显示（true 表示不回显）。
关键差异：
-
Console.Read()是流式字节/字符读取，受stdin缓冲策略影响（例如行缓冲） -
Console.ReadKey()是实时输入捕获，不经过标准输入流缓冲，因此能响应Ctrl+C前的任意键（但Ctrl+C本身会触发ConsoleCancelEventArgs） - 两者都不处理多字节 UTF-8 输入的粘包问题——.NET Core 3.0+ 默认用 UTF-8 编码控制台，但
Read()仍按 UTF-16 解码，对非 BMP 字符（如 emoji）可能拆成代理对
为什么 Console.In 被替换后 ReadLine() 还是读不到自定义输入？
因为 Console.In 是个静态属性，赋值后仅影响后续调用；但 Console.ReadLine() 内部其实缓存了初始的 TextReader 实例。也就是说，一旦程序启动，Console.ReadLine() 就绑定了最初的 Console.In，之后再改 Console.In = new StringReader("...") 对它无效。
正确做法：
- 必须在调用任何
Console.Read*方法前，先设置Console.SetIn(...) - 或者干脆别用
Console.ReadLine()，而直接调用Console.In.ReadLine()—— 它会动态读取当前Console.In - 注意：修改
Console.In后，原stdin句柄（如键盘）将不可恢复，除非你保存了原始Console.OpenStandardInput()流并手动切换回去
底层原理：Windows 和 Linux 上的输入路径完全不同
Windows 下，Console.Read* 最终调用 Win32 API ReadConsoleW（Unicode 版）或 ReadFile（ANSI 版），由 CSRSS 或新式 ConHost 处理键盘扫描码 → 字符映射 → 缓冲队列；而 .NET 通过 Interop.Kernel32.ReadConsole 封装，中间还经过编码转换（Console.InputEncoding 控制）。
Linux/macOS 下，.NET 使用 libc 的 read() 系统调用，但前提是把 /dev/tty 或 stdin 的终端设为 raw 模式（Console.ReadKey 会自动设置，ReadLine 不会）；否则默认是 canonical 模式，内核就帮你做了行缓冲和退格处理，应用层只能等到整行。
这意味着：
- 跨平台时不要假设
Console.Read()能读到退格键（\b）—— 在 canonical 模式下，它根本不会传给进程 -
Console.InputEncoding在 Windows 上影响实际解码，在 Unix 上基本被忽略（系统调用返回的是原始字节，.NET 按 UTF-8 解码） - 调试时用
strace -e read,write dotnet run（Linux）或 Process Monitor（Windows）能看到真实 I/O 调用，比看文档更准
