关键在于解码时使用的字符集必须与文件实际编码完全一致，不能依赖系统默认或猜测；Java字节流不带编码信息，乱码本质是“用错字典查字”，应使用InputStreamReader显式指定StandardCharsets.UTF_8等编码，避免FileReader无参构造导致跨平台乱码。
关键在于解码时使用的字符集必须与文件实际编码完全一致，不能依赖系统默认或猜测。Java 字节流本身不带编码信息，乱码本质是“用错字典查字”。
明确指定编码的 InputStreamReader
这是最常用也最稳妥的方式。避免使用无参的 FileReader（它用系统默认编码，Windows 是 GBK，Linux/macOS 通常是 UTF-8，极易不一致）。
- 从文件读取：用
Files.newBufferedReader(Paths.get("file.txt"), StandardCharsets.UTF_8) - 从类路径读取：用
new InputStreamReader(clazz.getResourceAsStream("/config.properties"), StandardCharsets.UTF_8) - 配合
BufferedReader使用，支持按行读取，代码清晰且性能好
先读字节再显式解码
适合需要并发加载、复用字节内容或统一预处理的场景。跳过任何隐式编码逻辑，全程可控。
- 用
Files.readAllBytes(path)或IOUtils.toByteArray(is)获取完整字节数组 - 用
new String(bytes, StandardCharsets.UTF_8)解码为字符串（确保文件无 BOM，否则需裁剪） - 再传给
StringReader加载，例如props.load(new StringReader(s)) - 该方式天然线程安全，每个线程操作自己的字符串，无共享状态风险
避开陷阱：别让编码“隐身”
很多乱码不是技术难点，而是被隐藏的默认行为误导。
-
FileReader没有构造函数接受编码参数，它永远用Charset.defaultCharset()，不可靠 -
new String(byte[])不带编码参数时，也走默认编码，和FileReader同源风险 -
Properties.load(InputStream)强制用 ISO-8859-1，读 UTF-8 的 .properties 文件必乱码——必须改用load(Reader) - JVM 启动参数
-Dfile.encoding=UTF-8可统一默认值，但不能替代显式指定，尤其在混合环境或容器中
验证与调试小技巧
遇到乱码不要只看结果，先确认源头：
- 用编辑器（如 VS Code、Notepad++）查看文件真实编码，右下角通常显示
- 打印前几个字节的十六进制值：
System.out.println(Arrays.toString(Arrays.copyOf(bytes, 8)))，对照 UTF-8/GBK 规则判断 - 对已知中文字符串，分别用
"你好".getBytes(StandardCharsets.UTF_8)和GBK对比字节数组差异
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
