为什么 System.in.read() 读不到单个字符？
Java 控制台默认是行缓冲的，System.in.read() 看似能读字节，但实际会等用户按回车才返回——你敲 a 不生效，得敲 a↵，第一个字节才是 a，后面跟着 \n 或 \r\n。这不是 bug，是输入流设计使然。
- 别用
Scanner.nextChar()（它根本不存在）或next().charAt(0)，后者依然要等回车 - Windows 下可用
Console.readPassword()隐蔽读取，但它也是一行一读，且不支持退格重输 - 真正实时响应单键，必须绕过标准输入流：Windows 用
javafx.scene.input.KeyCode不现实（非 GUI），推荐调用系统命令临时切到无缓冲模式
用 ProcessBuilder 调 stty -icanon -echo 可行吗？
不可行。那是 Unix/Linux 的终端控制命令，stty 对 Java 的 System.in 文件描述符无效——JVM 启动时已封装 stdin 为带缓冲的 InputStream，子进程改不了父进程的流行为。强行执行只会报 java.io.IOException: Cannot run program "stty": error=2, No such file or directory（Windows）或权限拒绝（Linux 容器里）。
- Mac/Linux 真想无缓冲读，得用 JNI 调
termios，或依赖jline3库的TerminalBuilder.builder().build() - Windows 可用
Kernel32.GetStdHandle+SetConsoleMode，但需jna，纯 JDK 无解 - 教学场景下，接受“按回车提交单字”是合理妥协，重点在逻辑而非实时性
如何安全地比对用户输入和目标字符？
别直接用 == 比字符，尤其涉及退格、换行、Unicode 组合字符时。char 是 UTF-16 单元，而用户粘贴的“é”可能由 e + ◌́ 两个码点组成，肉眼一样，char 值却不同。
- 比对前先用
String.normalize()转成 NFC 形式：target.normalize().equals(input.normalize()) - 练习软件通常只测 ASCII 字母数字，此时
Character.toLowerCase(c1) == Character.toLowerCase(c2)更轻量且防大小写误判 - 如果允许空格/标点，注意 Windows 控制台可能把
Ctrl+C发成\u0003，需在比对前过滤掉控制字符：Character.isISOControl(ch)
为什么打字计时总偏慢 100–300ms？
因为 System.nanoTime() 虽高精度，但启动时机不对：你在提示“开始”后才启动计时器，而用户视觉确认+手指反应有延迟。更糟的是，用 System.currentTimeMillis() 在某些 JVM 上受系统时钟调整影响，出现负耗时。
立即学习“Java免费学习笔记（深入）”；
- 计时起点应设在显示完题目、光标停在首字符位置的**那一帧之后**，不是
System.out.print("请输入：")之后 - 避免在循环里反复调
System.nanoTime()——它本身开销小，但频繁调用会干扰 JIT 优化，实测每秒超 10 万次才明显拖慢 - 真实打字软件会记录每个字符的
keyDown时间戳，Java 控制台做不到，所以“总耗时”只能从第一字输入开始算，别试图模拟按键级时间轴
控制台打字练习的边界很清晰：它不是终端模拟器，也不该变成 JNI 工程。把输入建模成“一行一交”，把反馈做准（错字标红、漏字提示），比纠结单键响应更重要。很多人卡在“必须实时”，其实用户真正需要的是即时反馈——哪怕延迟半秒，只要反馈内容对，体验就不差。
