Scanner适合简单交互式输入但性能差，BufferedReader高效但需手动解析；避免混用二者，读取时须统一考虑边界、编码与格式。
Scanner 适合简单交互式输入，但别在性能敏感场景用
如果只是读控制台的几行用户输入，比如菜单选择、单个数字或单词，Scanner 写起来最直觉：scanner.nextInt()、scanner.nextLine() 都很顺手。但它内部做了大量字符串解析和正则匹配，每次调用都会触发隐式分词和类型转换，开销不小。
常见错误是混用 nextInt() 和 nextLine()：前者不消费换行符，导致后续 nextLine() 立即返回空字符串。必须手动加一次 scanner.nextLine() 清掉缓冲区。
- 只用于开发调试、算法题、命令行小工具
- 避免在循环中反复创建
Scanner(System.in)实例（会重复绑定 stdin） - 不要用它读超大文件或高频输入（比如网络流、日志行解析）
BufferedReader 是 I/O 效率刚需时的首选
BufferedReader 本质是带缓冲的字符流包装器，只做“读行”或“读字符”，不做任何解析。它把字节流（如 System.in）转成字符流后，再缓存一整块数据，readLine() 基本就是从内存里拷字符串，速度比 Scanner 快 2–5 倍（尤其在 JDK 8+ 的典型测试中）。
注意它不能直接读数字——readLine() 返回 String，要转 int 得自己调 Integer.parseInt()；也**没有内置的分隔符跳过逻辑**，遇到空行或格式错位得自己处理。
立即学习“Java免费学习笔记（深入）”；
- 搭配
InputStreamReader(System.in)用，别直接包装System.in（那是字节流） - 读文件时优先用
Files.newBufferedReader(Paths.get("x.txt"))，更简洁且自动处理编码 - 若需按空格拆词，用
line.split("\\s+")，但注意正则开销；真要高性能分词，考虑StringTokenizer（已过时但轻量）或Pattern.compile().splitAsStream()
混合使用时，千万别让 Scanner 包裹 BufferedReader
有人想“取两者之长”，写成 new Scanner(new BufferedReader(...)) —— 这是典型误区。Scanner 自己就有缓冲机制，再套一层 BufferedReader 不仅没收益，反而因双重缓冲导致行为不可预测，比如 hasNextLine() 可能提前返回 false，或漏掉首行。
