在Java里Scanner和BufferedReader该如何选择_Java输入方式对比说明_技术教程

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。

每行必须手动 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 内部仍会做冗余解析