java中bufferedreader/writer的核心目的是通过内部缓冲区减少i/o调用，提升性能，但需显式指定编码、手动flush或用try-with-resources确保数据落盘，readline()返回null仅表示eof而非错误。
Java里用 BufferedReader 和 BufferedWriter 的核心目的不是“多加一层流”，而是避免每次读写都触发底层I/O——它们靠内部字符数组缓存批量操作，性能提升明显，但必须手动管理关闭和换行细节。
为什么不能直接 new BufferedReader(new FileReader(...)) 而不考虑编码？
因为 FileReader 默认使用平台编码（Windows是GBK，Linux/macOS通常是UTF-8），一旦文件实际编码与之不匹配，readLine() 就会读出乱码甚至抛 MalformedInputException。正确做法是绕过 FileReader，用带编码的构造链：
BufferedReader reader = new BufferedReader(
new InputStreamReader(new FileInputStream("data.txt"), StandardCharsets.UTF_8)
);
- 永远优先用
InputStreamReader+StandardCharsets显式指定编码 -
FileReader仅适合读纯ASCII或明确知道平台编码的场景 - 如果文件来自网络或用户上传，编码几乎一定得由外部传入，不能硬编码
BufferedWriter.write() 后内容没写到文件？
缓冲区未刷新（flush）是常见原因——write() 只把数据塞进内部字符数组，不立即落盘。尤其在程序异常退出或未调用 close() 时，最后一段内容会丢失。
- 显式调用
flush()确保缓冲区清空：writer.flush() -
close()会自动调用flush()，但仅限于正常执行到该语句；若中间抛异常，close()可能不被执行 - 推荐用 try-with-resources，它保证无论是否异常都会调用
close()：
try (BufferedWriter writer = new BufferedWriter(
new OutputStreamWriter(new FileOutputStream("out.txt"), StandardCharsets.UTF_8))) {
writer.write("hello");
writer.newLine(); // 注意：不是 \n，是平台相关换行符
}
readLine() 返回 null 是文件结束还是出错了？
readLine() 返回 null 仅代表已到达流末尾（EOF），不是错误。它不会抛异常来表示“读完了”，所以典型循环结构是：
立即学习“Java免费学习笔记（深入）”；
String line;
while ((line = reader.readLine()) != null) {
System.out.println(line);
}
- 如果
readLine()抛异常（如IOException），才是真实I/O问题，比如磁盘满、文件被占用 -
null不代表空行——空行返回的是空字符串"" - 注意：
readLine()自动剥离换行符（\r\n 或 \n），所以无法区分 Windows 和 Unix 换行风格
真正容易被忽略的是缓冲区大小和异常恢复能力：BufferedReader 默认8192字符，BufferedWriter 默认8192字节，对超大文本或高吞吐日志可能不够；而一旦底层流（如 FileInputStream）在读取中途被其他进程删除或截断，readLine() 可能静默返回 null 或抛异常——这时需要结合 available() 或文件长度校验做兜底，不能只信 null。
