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，或漏掉首行。
真正需要兼顾“高效读行 + 类型解析”的场景，推荐分层处理：
- 用
BufferedReader.readLine()拿整行 - 用
Scanner临时包装该行字符串：new Scanner(line).nextInt() - 或者更轻量：用
String::lines()（JDK 11+）配合Stream处理，避免对象频繁创建
从 System.in 切换到文件输入时，BufferedReader 更易迁移
Scanner 构造函数接受任意 Readable，看似灵活，但切换源后容易暴露隐藏问题：比如文件末尾无换行符时，nextLine() 在文件上可能阻塞或抛异常，而在控制台上却正常；又比如编码不一致导致中文乱码，Scanner 默认用平台编码且不暴露设置入口（JDK 9+ 才支持构造时传 Charset）。
BufferedReader 明确要求指定字符集（new InputStreamReader(in, StandardCharsets.UTF_8)），从设计上就迫使你面对编码问题，也更容易复用同一套读取逻辑处理不同来源。
真正难的不是选哪个类，而是意识到：输入流的边界（换行、编码、EOF）、数据格式（是否含空行、字段分隔符）、以及后续解析逻辑，这三者必须统一考虑。光盯着 API 简不简单，容易在上线后才发现吞了半行数据或卡死在某个特殊字符上。
