优先选 BufferedReader 处理大文本逐行读取，因其仅做 I/O 缓冲与换行识别，性能高；Scanner 适合格式化输入的灵活解析，但因内置词法分析、正则匹配和类型转换，性能低 2~5 倍。
选 BufferedReader 还是 Scanner，关键看需求：要快、要简单解析文本行，用 BufferedReader；要方便读取不同类型（int、double、单词等）且不介意性能损耗，用 Scanner。
BufferedReader 适合纯文本逐行读取
它底层基于字符缓冲区，只做“读字符串”这一件事，没有额外解析开销。适合处理大日志文件、配置文件、标准输入中按行处理的场景。
- 每次
readLine()返回一个String，无类型转换，零自动跳过空白逻辑 - 构造时必须包装一个
Reader（如new BufferedReader(new InputStreamReader(System.in))） - 不能直接读数字或跳过分隔符；想读整数？得自己
Integer.parseInt(line) - 对超长行或含 \r\n/\n/\r 的兼容性好，换行符处理由 JDK 统一保证
Scanner 更灵活但更慢
它本质是个带词法分析能力的解析器：内部维护缓冲区 + 正则匹配 + 类型转换 + 分隔符跳过逻辑。每调用一次 nextInt() 或 next()，都可能触发重缓冲、正则匹配、异常捕获和装箱操作。
- 默认以空白符（空格、tab、换行等）为分隔符，
next()只读一个“token”，不是一整行 -
nextLine()行为特殊：会消费掉前一个nextXXX()留下的换行符，容易漏读，需注意调用顺序 - 支持自定义分隔符（
useDelimiter()）、跳过注释、匹配正则，适合格式化输入（如竞赛题、命令行参数） - 在循环中频繁调用
hasNextInt()+nextInt()，比BufferedReader.readLine()+parseInt()慢 2~5 倍（实测常见于百万级数据）
性能差异的核心原因
不是“谁用了缓冲”，而是“谁做了更多事”。两者都用了缓冲（Scanner 内部也包装了 BufferedInputStream 或类似），但差异在于：
立即学习“Java免费学习笔记（深入）”；
- BufferedReader：只做 I/O 缓冲 + 字符解码 + 换行识别 → 开销低、可预测
- Scanner：I/O 缓冲 + 解码 + 分隔符切分 + 正则匹配（默认空白）+ 类型解析 + 异常处理 + 对象创建（如 Integer）→ 链路长、分支多、GC 压力略高
实际怎么选？看这几点
- 读大文件、追求吞吐量（如日志分析、ETL预处理）→ 无条件选 BufferedReader
- 写算法题、读格式明确的控制台输入（如“第一行n，第二行n个数”）→ Scanner 更省代码，小数据下差异可忽略
- 需要混合读取：先读几行配置，再读一堆数字 → 可组合使用：
BufferedReader读行，遇到数字行再用new Scanner(line)拆解（避免全局 Scanner 的状态干扰） - 注意资源释放：两者都实现了
AutoCloseable，务必 try-with-resources，尤其BufferedReader包装网络或文件流时
