java中filereader读取中文乱码源于“读的编码≠文件存的编码”，不会抛异常而是静默错解；应弃用filereader，改用files.newbufferedreader或inputstreamreader显式指定standardcharsets.utf_8等编码，避免依赖jvm默认值和拼写错误。
Java中FileReader读取中文乱码，通常不会抛出编码解析错误，而是静默错解——比如显示“ä½ å¥½”或“????”，底层是字节被用错误编码（如GBK）强行映射成字符，过程无异常，但结果不可逆。所谓“抛出编码解析错误”，实际多见于你手动传入非法编码名（如"utf8"、"UTF8"），此时会触发UnsupportedEncodingException。
确认文件真实编码再操作
别猜，先查。乱码根源永远是“读的编码 ≠ 文件存的编码”：
- Linux/macOS下运行：
file -i filename.txt，看输出中的charset=字段 - Windows下用VS Code打开文件，右下角状态栏直接显示当前识别的编码（如UTF-8、GBK）
- 若用记事本保存过，大概率带BOM的UTF-8；用IDEA/IntelliJ新建的文件，默认无BOM UTF-8
弃用 FileReader 构造器的编码参数
虽然JDK 11+为FileReader增加了String charsetName重载，但该API设计已被视为过渡兼容，官方文档明确标注“不推荐用于新代码”。更关键的是：
- 传参写错就崩：“utf8”“UTF8”“utf-8”三者只有
"UTF-8"合法，大小写敏感 - 即使参数正确，
FileReader仍是基于InputStreamReader的薄封装，没有额外健壮性 - 跨平台项目中，依赖它等于把编码决策权交给JVM默认值，风险不可控
改用标准且显式的流组合
真正可靠的做法，是绕过FileReader，用字节流转字符流的显式链路：
- 读UTF-8文件：
Files.newBufferedReader(Paths.get("a.txt"), StandardCharsets.UTF_8) - 读GBK文件：
new BufferedReader(new InputStreamReader(new FileInputStream("a.txt"), "GBK")) - 统一推荐写法（带自动资源管理）：
try (BufferedReader br = Files.newBufferedReader(Paths.get("data.txt"), StandardCharsets.UTF_8)) {
String line;
while ((line = br.readLine()) != null) {
System.out.println(line); // 中文正常
}
}
这行代码明确绑定UTF-8，不依赖系统默认值，也不会因编码名拼写错误而运行时崩溃——编译期就用StandardCharsets.UTF_8确保类型安全。
警惕BOM和大文件陷阱
两个容易忽略但高频踩坑点：
-
BOM问题：UTF-8文件若含BOM（
EF BB BF），Files.newBufferedReader能自动跳过；但若用InputStreamReader手动构造，需自行检测并跳过前3字节，否则首行开头可能多出“\uFEFF” -
内存风险：
Files.readAllLines()会一次性加载全文件到内存，10MB以上易OOM；流式读取（BufferedReader）才是生产环境标配
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
