Scanner适合交互式输入但性能差，BufferedReader适合批量高速读取；混合使用可兼顾速度与便利性；竞赛刷题首选BufferedReader。
Scanner 适合交互式输入但性能差
当程序需要从控制台读取用户逐行、逐词或逐数字输入（比如命令行小工具、算法题输入），Scanner 最直观。它内置类型解析，nextInt()、nextLine()、nextDouble() 直接返回对应类型，不用手动 parseInt 或 Double.parseDouble。
但它的底层是基于 BufferedReader 封装的，额外做了分词、正则匹配和类型转换，带来明显开销。在输入量大（如百万级整数）时，Scanner 可能比 BufferedReader 慢 3–5 倍。
-
nextLine()和nextInt()连用容易漏掉换行符：调用nextInt()后缓冲区还剩\n，紧接着nextLine()会立刻返回空字符串 - 默认分隔符是空白符（空格、tab、换行），不能直接读含空格的单行字符串而不被截断——得用
useDelimiter("\n")配合next()，反而绕路 - 不支持设置编码，始终用平台默认字符集，读取 UTF-8 文件可能乱码
BufferedReader 适合批量读取文件或高速输入
BufferedReader 是纯文本流处理器，只管按行（readLine()）或按字符（read()）拉取原始字符串，不做任何解析。这意味着你得自己拆分、转换类型，但换来的是稳定、可控、接近 I/O 极限的速度。
它必须包装一个 Reader，常见组合是 new BufferedReader(new InputStreamReader(System.in, StandardCharsets.UTF_8))，显式指定编码可避免中文乱码；读文件时直接包装 FileReader 或带编码的 InputStreamReader。
使用 ImageMagick 的 convert 和 mogrify 命令进行批量图像处理，支持调整大小、裁剪、水印和格式转换。与 libvips 集成以实现高性能缩略图生成。
立即学习“Java免费学习笔记（深入）”；
- 每行必须手动
Integer.parseInt(line)或Long.parseLong(line)，遇到格式错误会抛NumberFormatException，需 try-catch -
readLine()返回null表示流结束，这是唯一可靠的 EOF 判断方式，别用ready()做循环条件 - 如果需要读单个字符或跳过空白，
BufferedReader不提供类似Scanner.skip()的便捷方法，得自己缓存或重写逻辑
混合使用：BufferedReader 读行 + Scanner 解析单行
真有“既要速度又要方便”的场景（比如一行多个整数用空格分隔），可以折中：用 BufferedReader 快速读整行，再用 Scanner 临时解析该行内容。这样避开 Scanner 的全局分词开销，又省去手撕 split(" ") 和异常处理。
BufferedReader br = new BufferedReader(new InputStreamReader(System.in, StandardCharsets.UTF_8));
String line = br.readLine();
if (line != null) {
Scanner lineSc = new Scanner(line);
while (lineSc.hasNextInt()) {
int x = lineSc.nextInt();
// 处理 x
}
}
- 注意：每次新建
Scanner开销很小，但别在循环内反复 new 同一个Scanner包装同一行——没意义 - 这招对“每行固定字段数”的输入（如 CSV 片段）很实用；但若每行结构差异大，不如统一用
split()+tryParse工具方法 - 别用
Scanner包装BufferedReader（如new Scanner(br)），这会丢失BufferedReader的缓冲优势，且Scanner内部仍会做冗余解析
竞赛/刷题场景下几乎只用 BufferedReader
LeetCode、Codeforces、牛客网等平台的 Java 输入样例通常数据量大、格式规整（如第一行 n，接下来 n 行每行一个数），此时 BufferedReader 是事实标准。几乎所有高分 Java 提交都用它，不是因为“更高级”，而是因为快、稳、少出错。
- 别为了省几行代码用
Scanner导致 TLE（超时）——尤其输入 10⁵ 行以上时 - 本地调试可先用
Scanner快速验证逻辑，提交前统一换成BufferedReader - 记得关流：虽然
System.in不必 close，但读文件时br.close()或用 try-with-resources，否则可能句柄泄漏
Scanner；文件/标准输入大数据 → BufferedReader；中间地带，优先 BufferedReader + 字符串切分，而非妥协回 Scanner。编码、异常、换行符处理这些细节，漏掉一个就卡半天。 
