Scanner适合类型明确的简单交互，BufferedReader适合高吞吐纯文本处理；Scanner自动类型转换但易出错、性能低、编码受限，BufferedReader高效可控但需手动解析；二者不可混用同一System.in流。
读取用户输入时，Scanner 更适合简单、类型明确的交互场景；BufferedReader 更适合高吞吐、纯文本流处理，尤其是需要逐行读取或配合 InputStreamReader 处理编码的场合。
什么时候该用 Scanner？
Scanner 本质是带词法分析的解析器，适合“按类型读”——比如你要连续读一个整数、一个浮点数、一个字符串，它能自动跳过空白、识别分隔符、做类型转换。
- 常见错误：用
nextLine()接在nextInt()后，结果直接返回空字符串——因为nextInt()不消费换行符，nextLine()立刻读到残留的\n - 解决办法：在
nextInt()后加一次nextLine()清缓冲，或统一用nextLine()+Integer.parseInt() - 性能敏感场景慎用：每次调用
nextXXX()都会重新编译正则匹配分隔符（默认是空白），开销比纯读取大不少 - 不支持指定字符集直接构造（除非传
InputStream+Charset），默认依赖系统编码，跨平台读中文易乱码
为什么 BufferedReader 更快更可控？
BufferedReader 是纯粹的字符缓冲读取器，不做任何解析，只负责高效地把字节转成字符、缓存、按需吐出——所以它快，也更底层、更灵活。
- 必须包装
InputStreamReader才能从System.in读：例如new BufferedReader(new InputStreamReader(System.in, StandardCharsets.UTF_8)) - 只提供
read()、readLine()、ready()等基础方法，没有nextInt()这类便利但隐含逻辑的方法 - 读到
null表示流结束（如 Ctrl+D / Ctrl+Z），不是异常，要主动判断 - 如果需要按空格拆分某一行，得手动调用
String.split()或StringTokenizer，但这也意味着你能精确控制分隔逻辑
Scanner 和 BufferedReader 能不能混用？
不能共用同一个 System.in 流。一旦任一对象调用了 read() 或 nextXXX()，就会消耗底层字节，另一个对象再读就会“丢数据”或阻塞在错误位置。
立即学习“Java免费学习笔记（深入）”；
- 典型症状：先用
Scanner读了一行，再新建BufferedReader去读——后者可能直接阻塞，或读到意外内容 - 根本原因：
System.in是单向字节流，不可 rewind，缓冲区状态不共享 - 若必须切换，只能关闭旧对象并确保没残留未读字节（实践中几乎不可靠），推荐全程只选一种
真正容易被忽略的是：很多教程把 Scanner 当作“标准输入唯一解”，但它在处理混合输入（比如一行里有数字和字符串，中间还夹着特殊符号）或需要严格编码控制时，反而会让逻辑变脆弱。这时候宁可多写两行 split 和 parse，也要用 BufferedReader 把读和解析拆开。
