Files.newBufferedReader() 默认硬编码使用StandardCharsets.UTF-8，不支持其他编码；若文件为GBK等非UTF-8编码且未显式指定Charset，将静默乱码；必须显式传入对应Charset（如StandardCharsets.GBK）才能正确读取。
Files.newBufferedReader() 为什么不能直接用 UTF-8 以外的编码？
因为 Files.newBufferedReader() 的重载方法中，不显式传入 Charset 时，默认使用 StandardCharsets.UTF_8 —— 这是 Java 7+ 的硬编码行为，不是系统默认编码。如果你的文件是 GBK、ISO-8859-1 或 UTF-16，不指定 charset 就会乱码，且不会抛异常，只会静默解码失败。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 永远显式传入
Charset：比如Files.newBufferedReader(path, StandardCharsets.GBK) - 别依赖
Charset.defaultCharset()，它在不同环境（IDE / Docker / Windows / Linux）下可能不同，且与文件真实编码无关 - 若需自动探测编码（如处理未知来源的 CSV），
Files.newBufferedReader()不支持，得换用第三方库（如 juniversalchardet）先猜编码，再构造 Reader
如何安全关闭 Files.newBufferedReader() 创建的 BufferedReader？
它返回的是标准 BufferedReader，但底层封装了 FileChannel 和 InputStream，资源必须释放。不关会导致文件句柄泄漏，尤其在循环读取大量小文件时，很快触发 java.io.IOException: Too many open files。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 优先用 try-with-resources：
try (BufferedReader reader = Files.newBufferedReader(path, StandardCharsets.UTF_8)) { String line; while ((line = reader.readLine()) != null) { // 处理 } } - 不要手动调用
reader.close()后再用 try-finally —— 它不如 try-with-resources 简洁，且容易漏掉异常覆盖 - 注意：
Files.newBufferedReader()返回的 reader 关闭时，也会关闭其背后的InputStream，无需额外操作
Files.newBufferedReader() 和 new BufferedReader(new FileReader(...)) 有啥实质区别？
核心差异在底层通道和异常语义：Files.newBufferedReader() 基于 FileChannel.open() + Channels.newReader()，抛出的是 IOException；而 FileReader 是老式基于 FileInputStream 的封装，内部仍用 Charset.defaultCharset() 且不支持非 UTF-8 显式指定（除非绕路用 InputStreamReader）。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 新项目一律用
Files.newBufferedReader()，它更符合 NIO.2 设计，路径支持Path类型，语义清晰 - 避免混合写法如
new BufferedReader(new InputStreamReader(Files.newInputStream(path), StandardCharsets.UTF_8))—— 多余套了一层，性能略差，且没收益 - 如果需要带缓冲大小控制（如超大行处理），
Files.newBufferedReader()不暴露 buffer size 参数，此时应退回到InputStreamReader+BufferedReader手动组合
读取超大文本文件时，Files.newBufferedReader() 会 OOM 吗？
不会——它本身不缓存整文件，只是按需读取字符缓冲区（默认 8192 字符）。OOM 通常来自业务逻辑：比如把每行 readLine() 结果全塞进 List<string></string>，或对每行做正则全局匹配生成巨量 MatchResult 对象。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 流式处理：边读边处理，避免累积中间集合
- 慎用
lines()：虽然Files.lines(path)返回Stream<string></string>看似函数式，但它底层仍用Files.newBufferedReader()，且 stream 不 close 会导致资源泄漏 —— 必须用 try-with-resources 包裹或显式stream.close() - 遇到超长行（如单行几百 MB 的 JSON），
readLine()可能撑爆堆，此时应改用read(char[], int, int)分块读，或切到Scanner配合自定义分隔符
Files.newBufferedReader() 看似简单，但 charset 选错、close 忘记、stream 未关、超长行假设，任何一个点都可能让程序在某个环境里悄无声息地崩掉。 
