newLine()足够跨平台换行，因它在BufferedWriter创建时即缓存系统line.separator值；需搭配UTF-8编码避免乱码，推荐try-with-resources确保flush和close。
不需要手动配合 System.lineSeparator() ——BufferedWriter 的 newLine() 方法内部已经自动使用它，直接调用即可实现跨平台换行。
为什么 newLine() 就够了
newLine() 在构造时就从系统属性 line.separator 读取了当前平台的换行符（Windows 是 \r\n，Linux/macOS 是 \n），并缓存为 lineSeparator 字段。每次调用都原样写入这个值，完全无需你干预。
- 它不是“动态查系统”，而是在
BufferedWriter实例创建时一次性确定，稳定且高效 - 只要 JVM 运行在目标环境（比如部署到 Windows 服务器），写出来的换行符天然适配该平台
- 手动调用
System.lineSeparator()再写入，反而绕过缓冲机制，失去性能优势
必须搭配正确的字符编码
换行符只是文本格式的一部分；若文件含中文、法文等特殊字符，编码不一致会导致乱码，破坏实际可读性。
-
FileWriter不支持指定编码，会用系统默认编码（Windows 上常是 GBK），极易出错 - 正确做法：用
OutputStreamWriter显式指定StandardCharsets.UTF_8，再套BufferedWriter - 示例：
new BufferedWriter(new OutputStreamWriter(new FileOutputStream("log.txt"), StandardCharsets.UTF_8))
别忘了 flush 和 close
BufferedWriter 是带缓冲的，内容不会立刻落盘。如果程序异常退出或忘记关闭，最后一段内容可能丢失。
立即学习“Java免费学习笔记（深入）”；
- 推荐使用 try-with-resources，自动完成
close()（它内部会先flush()） - 若需中途确保内容已写入（如日志实时查看），主动调用
flush() - 避免只调用
flush()而不close()：资源未释放可能引发句柄泄漏
什么情况下 newLine() 不适用
它的跨平台逻辑是“运行在哪、适配哪”。如果你明确要求文件**必须用 Windows 换行符**（\r\n），但程序却运行在 Linux 环境下，那 newLine() 会写入 \n，不符合需求。
- 此时应放弃跨平台写入逻辑，改用
write("\r\n") - 但注意：这属于特例，不是常规推荐；多数场景下，让换行符匹配运行环境更合理
- 若需统一换行风格（如 Git 提交前标准化），应在构建或部署环节做转换，而非在 Java 写入时硬编码
