核心是让bufferedreader真正发挥缓冲作用，需显式指定utf-8编码、按场景调优缓冲区大小、坚持使用readline()、用try-with-resources确保及时释放资源。
核心是让 BufferedReader 真正发挥缓冲作用，而不是只把它当个“带 readLine() 的 Reader”来用。默认配置能应付一般文件，但面对大型文本（如日志、导出报表、ETL 原始数据），必须针对性调优。
显式指定 UTF-8 编码，杜绝乱码与隐式解码开销
不指定编码时，BufferedReader 会依赖平台默认 Charset（Windows 是 GBK，Linux/macOS 多为 UTF-8），不仅易导致中文乱码，还会在每次字符转换时多一层不确定的解码逻辑，拖慢吞吐。尤其大文件中频繁跨字节边界时，错误编码会引发额外异常处理或静默截断。
- ✅ 正确写法：用
Files.newBufferedReader(Paths.get("data.log"), StandardCharsets.UTF_8) - ✅ 或手动构造：用
InputStreamReader显式套FileInputStream+UTF_8，再包 BufferedReader - ❌ 避免：
new FileReader("data.log")—— 它隐式使用平台默认编码，不可控
按场景调整缓冲区大小，避开默认 8KB 的“一刀切”
默认 8192 字节（约 8KB）是通用经验值，但对超长行（如单行 JSON、base64 内容、宽字段 CSV）容易触发多次缓冲填充，增加系统调用次数；而对高频小行（如每行仅几十字节的日志），又可能浪费内存且无实质收益。
- ✅ 行平均长度 > 2KB：可设为
65536（64KB），减少 fill() 调用频次，提升吞吐 - ✅ 实时性要求高（如监控流式输入）：保持默认或设为
4096，降低延迟敏感度 - ❌ 不要盲目设成 1MB+：堆内存占用陡增，GC 压力大，高并发下易 OOM
坚持用 readLine()，禁用逐字符/逐字节读取模式
BufferedReader 的性能优势几乎全部来自 readLine() 对内部 char[] cb 缓冲区的批量扫描能力。一旦改用 read() 或 read(char[]) 手动解析换行，就退化为“带一层 char 中转的 InputStream”，失去核心加速逻辑。
- ✅ 每次循环只调
reader.readLine()，判 null 即可终止 - ✅ 若需跳过空行或过滤，用
line != null && !line.trim().isEmpty()，别拆成 char 数组遍历 - ❌ 禁止：
while ((c = reader.read()) != -1)—— CPU 使用率飙升，速度可能只有 readLine() 的 1/10
用 try-with-resources 确保资源及时释放，避免句柄泄漏
大文件读取常伴随长时间运行或高频启停，若未正确关闭，底层 FileInputStream 句柄会持续占用，系统级文件描述符耗尽后，后续任何 IO 都会失败（抛 IOException: Too many open files）。
- ✅ 写法：
try (BufferedReader r = Files.newBufferedReader(...)) { ... } - ✅ 关闭 BufferedReader 会自动递归关闭其包装的 InputStreamReader 和 FileInputStream
- ❌ 不要只关外层还手动关内层，也不要在 finally 块里重复 close（可能 NPE）
