BufferedWriter高效写入需控节奏：显式指定UTF-8编码、write()与newLine()分步调用、用try-with-resources确保flush和close。
用 bufferedwriter 高效写入文本变量，关键不在“堆内容”，而在“控节奏”——即合理利用缓冲、明确换行职责、规避平台陷阱。它不是越快越好，而是越稳越高效。
先包装好带编码的底层流
直接用 FileWriter 构造 BufferedWriter 会默认使用系统平台编码（如 Windows 的 GBK），极易导致跨环境乱码。必须显式指定字符集：
- 推荐用
OutputStreamWriter+FileOutputStream组合，传入StandardCharsets.UTF_8 - 避免
new FileWriter("x.txt")这类无编码声明的写法 - 若用 NIO 的
Files.newBufferedWriter()，也务必传StandardCharsets.UTF_8
写一行 = write() + newLine()，不可省略任一环
BufferedWriter 没有类似 PrintWriter.println() 的单方法封装。所谓“写一行”，本质是两个原子动作：
-
write("内容")：只把字符塞进缓冲区，不换行 -
newLine()：单独插入当前 JVM 所在平台的换行符（\r\n或\n） - 二者顺序不能颠倒；也不能用
write("内容\n")替代，否则失去跨平台性
newLine() 的适配逻辑与边界情况
newLine() 能自动适配，是因为它内部调用 System.lineSeparator()，而该值由 JVM 启动时读取系统属性 line.separator 决定：
- 运行在 Windows 上 → 写
\r\n - 运行在 Linux/macOS 上 → 写
\n - 如果目标文件必须在 Windows 上打开（比如被 Excel 或旧工具解析），但程序部署在 Linux 服务器上，则
newLine()不满足需求——此时应手动write("\r\n")，但这已不属于“跨平台写入”，而是“定向兼容”
确保内容真正落地：flush 和 close 不可少
缓冲区内容不会自动落盘。常见疏漏：
- 忘记
flush()：程序异常退出或未关闭流时，最后一段内容可能丢失 - 依赖
close()自动 flush：虽规范如此，但若中间发生异常，close()可能不被执行 - 最佳实践：用
try-with-resources，既简洁又安全，JVM 保证close()被调用
