BufferedReader 比 Scanner 快因纯字符缓冲读取、无解析开销，性能高3–5倍；需经 InputStreamReader 包装 System.in 并显式指定编码；readLine() 返回 null 仅表示 EOF，空行返回 ""；PrintWriter 需启用自动 flush 或手动调用。
BufferedReader 为什么比 Scanner 快
因为 BufferedReader 是纯字符流缓冲读取，不解析数据类型，只做字节到字符的批量转换；而 Scanner 在每次 nextXXX() 调用时都要触发正则匹配、类型转换和分隔符跳过，开销大得多。尤其在读取大量整数或字符串时，性能差距可达 3–5 倍。
实操建议：
- 处理纯文本行（如日志、配置、CSV 行）优先用
BufferedReader - 需要按空格/制表符拆分并转
int/double等类型时，可先用BufferedReader.readLine()读整行，再用String.split()+Integer.parseInt()手动解析——更可控，也比Scanner稳定 - 注意：如果输入含 Unicode 补充字符（如 emoji），
BufferedReader默认使用平台默认编码，可能乱码；应显式指定InputStreamReader编码
如何正确初始化 BufferedReader 包装 System.in
不能直接对 System.in 构造 BufferedReader，必须经由 InputStreamReader 转换字节流为字符流，否则编译失败。
常见错误写法：
BufferedReader br = new BufferedReader(System.in); // ❌ 编译报错：构造函数不接受 InputStream
立即学习“Java免费学习笔记（深入）”；
正确写法（推荐带编码）：
BufferedReader br = new BufferedReader(
new InputStreamReader(System.in, StandardCharsets.UTF_8)
);
说明：
-
StandardCharsets.UTF_8显式指定编码，避免 Windows 下默认GBK导致中文输入乱码 - 若用
new InputStreamReader(System.in)不指定编码，行为依赖系统属性file.encoding，不可移植 - 不需要手动
close()System.in，但为代码一致性，建议配合 try-with-resources（JDK 7+）
readLine() 返回 null 的真实含义
BufferedReader.readLine() 返回 null **仅表示输入流已到达末尾（EOF）**，不是错误，也不是空行。空行返回的是空字符串 ""。
典型误判场景：
- 把
null当作“用户没输内容”处理，导致提前退出 - 用
while ((line = br.readLine()) != null)读标准输入时，在终端中需按Ctrl+D（Linux/macOS）或Ctrl+Z（Windows）才触发 EOF，否则循环永远阻塞 - 从文件读取时，
null出现在最后一行之后；但若文件末尾有换行符，最后一行是""，再下一次才是null
所以判断空输入应写成：
String line = br.readLine();
if (line != null && !line.trim().isEmpty()) {
// 处理非空行
}
BufferedReader 和 PrintWriter 搭配输出时的刷新问题
用 PrintWriter 写入后不调用 flush() 或 println()（带换行的自动 flush），输出可能滞留在缓冲区，终端或文件看不到内容，尤其在重定向或管道场景下更明显。
实操要点：
- 创建
PrintWriter时，第二个参数设为true启用自动 flush：PrintWriter out = new PrintWriter(System.out, true); // ✅ 自动 flush
- 若设为
false（默认），必须显式调用out.flush()或out.println()（后者内部会 flush） - 不要混用
System.out.print()和PrintWriter输出同一目标（如都往System.out），缓冲行为不一致，可能导致顺序错乱
BufferedReader 的核心价值不在“功能多”，而在“快且轻”。真正容易出问题的，从来不是怎么读，而是编码没对、EOF 判错、缓冲没刷——这些地方一漏，程序就卡在看不见的地方。
