大文本处理应避免StringBuilder一次性拼接转String，优先采用BufferedReader逐行流式处理、BufferedWriter直接写出、Collectors.joining()替代手动累积，超大文件则分块读写中转。
大文本处理不该靠 StringBuilder 一股脑拼完再转 String，尤其当数据源来自文件、网络或数据库流式读取时——直接拼装会把全部内容塞进堆内存，极易触发频繁 GC 甚至 OOM。字符流的核心价值是“边读边处理”，避免一次性加载。
用 BufferedReader + 字符流逐行处理
面对日志文件、CSV 或大 XML，优先用 BufferedReader 按行读取，配合 StringBuilder 做局部拼接，而不是先读全再组装：
- 每次只 hold 一行内容，内存占用稳定在 KB 级，不随文件大小线性增长
- 可结合条件过滤、格式转换、分段写入等逻辑，无需缓存全文
- 示例：统计某字段出现次数，只需读一行、解析一行、累加一次，完全不用拼字符串
写入大文本时用 BufferedWriter 替代 toString()
如果最终目标是写入文件或响应输出，别调用 sb.toString() 再写入，而是直接用 BufferedWriter 把 StringBuilder 的内容 flush 出去：
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 避免中间生成一个巨型 String 对象（它本身还要复制 char[]）
- BufferedWriter 内部也带缓冲区，可批量写出，减少系统调用次数
- 关键写法：writer.write(sb.toString()) 是错的；应改用 writer.append(sb).flush()（注意 append 支持 CharSequence，无需转 String）
流式拼接场景用 Stream + Collectors.joining() 代替手动累积
若数据已封装为 List 或 Stream（如从数据库查出的百万条记录 ID），不要 for 循环 append 到 StringBuilder，而应交给收集器：
立即学习“Java免费学习笔记（深入）”；
- Collectors.joining(", ") 底层用 StringBuilder 实现，但做了容量预估与线程安全封装
- 它不生成中间 String，也不暴露 StringBuilder 实例，语义清晰且不易出错
- 大数据量时可配合 Stream.iterate 或 Files.lines() 实现真正流式处理，内存峰值可控
超大文本合并时考虑分块 + 文件临时中转
当必须“拼接”多个 GB 级文本文件时，内存再优化也难扛住。此时字符流要配合文件操作：
- 用 FileReader → BufferedReader → FileWriter → BufferedWriter 链式传递
- 每读一块（如 8KB），处理后立即写入目标文件，全程无大对象
- 若需插入分隔符或头部/尾部内容，可在每次 write 前用小 StringBuilder 组装该块的结构，而非全局拼接
