流式导出需显式指定utf-8编码并用bufferedwriter.newline()实现跨平台换行，禁用硬编码"\n"或"\r\n"；务必flush与try-with-resources保障完整性；特殊场景才强制crlf并明确声明。
用 OutputStreamWriter 做流式导出时，换行符不是“写个 \n 就完事”的小事——它直接决定文件在 Windows、Linux 或 macOS 上能否被正确识别为多行文本。所谓“语义灾难”，就是你写的文件在记事本里变成一整行（Windows 下遇 \n 不换行），或在 Vim 里满屏 ^M（Linux 下混入 \r\n），本质是换行符语义与目标平台解析规则错配。
别让 OutputStreamWriter 自己猜编码
换行符只是冰山一角，真正的第一道防线是字符编码：
-
FileWriter不能用——它隐式依赖系统默认编码（Windows 常是 GBK），导出含中文的 CSV 或日志极易乱码 - 必须显式用
OutputStreamWriter包装字节流，并指定StandardCharsets.UTF_8 - 例如：
new OutputStreamWriter(outputStream, StandardCharsets.UTF_8)
换行动作必须交给 BufferedWriter.newLine()
OutputStreamWriter 本身没有 newLine() 方法；它是字符输出流，只负责编码转换。真正做“跨平台换行”的是它的上层包装器：
- 把
OutputStreamWriter套进BufferedWriter，再调用bufferedWriter.newLine() - 这个方法内部固定读取
System.lineSeparator()，JVM 运行在哪，就写哪的换行符（\r\n或\n） - 绝对不要在
OutputStreamWriter上直接write("\n")或write("\r\n")——这等于绕过平台适配逻辑，制造硬编码陷阱
流式导出必须兼顾实时性与完整性
导出过程常持续数秒甚至分钟，用户可能中途查看临时文件，或服务异常中断：
- 启用自动 flush：构造
PrintWriter时传true（如用于 Socket 或 HTTP 响应流） - 手动控制更稳妥：每写完一条逻辑记录（如一行 CSV），调用
bufferedWriter.flush() - 务必用
try-with-resources包裹BufferedWriter，确保close()被调用——它会先flush()再释放资源，避免最后一段内容丢失
特殊场景要提前做平台语义声明
如果导出文件明确要求“必须 Windows 风格换行”（比如供 Excel VBA 脚本读取），而你的服务部署在 Linux 容器里，newLine() 就不适用：
- 此时放弃“运行在哪适配哪”，改用
write("\r\n")强制写入 - 但需在文档或配置中标明：“本导出强制使用 CRLF 换行，与运行环境无关”
- 更可持续的做法是：导出后由构建流水线统一转码（如用
dos2unix/unix2dos），Java 层保持中立
