BufferedWriter 比 FileWriter 快因默认8192字节缓冲减少系统调用；需手动flush()确保数据落盘；换行用newLine()而非"\n"；必须显式指定UTF_8编码并用try-with-resources管理资源。
BufferedWriter 为什么比 FileWriter 快
因为 FileWriter 每次调用 write() 都触发一次系统调用，而 BufferedWriter 默认用 8192 字节缓冲区暂存数据，等满、flush() 或 close() 时才批量落盘。一次系统调用耗时约几百纳秒，反复调用在写入 10 万行时可能慢几十倍。
但缓冲区不是越大越好：new BufferedWriter(writer, 65536) 在内存紧张或崩溃风险高时反而得不偿失。默认值够用，除非你明确知道单行常超 4KB——这时可设为 16384 或 32768，避免频繁刷盘。
必须手动 flush() 的三个关键时机
BufferedWriter 不会在缓冲区未满时自动刷盘，JVM 退出也不会帮你兜底。常见“文件只写了一半”就是漏了这步。
- 循环中写入中途需确保内容已落盘（如日志轮转、断点续传）→ 立即调用
bw.flush() - 全部写完后、关闭前 → 必须先
bw.flush()，再bw.close()；仅close()虽会尝试 flush，但若抛出异常，这步就被跳过 - 捕获到
IOException后还想继续写 → 别直接重试，先bw.flush()看是否能清空脏缓冲区，否则后续写可能持续失败
换行符和批量写入的坑
手写 "\n" 在 Windows 上会导致文本编辑器显示为一行，因为真实换行符是 "\r\n"。最安全的是用 bw.newLine()，它内部调用 System.lineSeparator()。
立即学习“Java免费学习笔记（深入）”；
别在循环里拼大字符串再写，例如：
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
String all = String.join("\n", lines);
bw.write(all);
这既跨平台错乱（没用 System.lineSeparator()），又失去缓冲优势（一次性占满堆内存）。应改为：
for (String line : lines) {
bw.write(line);
bw.newLine();
}
更别用 bw.append(str).append("\n") —— 每次 append() 都检查缓冲区容量，开销比 write() 大。
编码与资源管理的硬性要求
性能瓶颈常不在 BufferedWriter 本身，而在底层：用 FileWriter 默认编码（平台相关）或漏设 StandardCharsets.UTF_8，会导致隐式编码转换拖慢速度；用 OutputStreamWriter 却没传 charset，也会掉进陷阱。
务必用 try-with-resources，且显式指定编码：
try (BufferedWriter bw = new BufferedWriter(
new OutputStreamWriter(
new FileOutputStream("out.txt"),
StandardCharsets.UTF_8))) {
// 写入逻辑
}
不用 FileWriter 包装器——它不支持指定编码，且构造时若传 String 路径，无法控制 Charset。
真正容易被忽略的是：缓冲区大小、flush() 时机、换行符来源、编码一致性，这四点任何一个出错，都可能让性能优化归零，甚至引发数据丢失或乱码。
