charset.defaultcharset()返回值即当前jvm实际生效的默认字符集，由启动时-dfile.encoding或系统locale决定且不可变；system.getproperty("file.encoding")仅是属性值，修改不影响实际编码行为。
直接查 Charset.defaultCharset() 的返回值，就能确认当前 JVM 实际生效的 file.encoding 效果——这是最核心、最可靠的排查方式。
怎么看当前生效的 file.encoding？
运行以下代码即可直观获知：
System.out.println(Charset.defaultCharset());
System.out.println(System.getProperty("file.encoding"));
注意两点：
-
前者是真实起作用的默认编码，由 JVM 启动时根据
file.encoding属性或系统 locale 决定，后续不可变； -
后者只是系统属性值，可能被手动 set 过（如
System.setProperty("file.encoding", "GBK")），但不会影响defaultCharset()—— 这是常见误判点。
哪些地方会受 file.encoding 影响？
它不控制所有编码行为，只在未显式指定编码的场景下兜底生效，典型包括：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
-
String.getBytes()和new String(byte[])（无参重载）； -
FileReader/FileWriter（已过时，但仍有项目在用）； -
InputStreamReader/OutputStreamWriter构造时未传 Charset； -
URLEncoder.encode(String)（JDK 10+ 已要求必须传 charset，旧版仍依赖 default）； - XML 解析器读取无声明编码的文件（如
<?xml version="1.0"?>缺少encoding="..."）； - 日志框架（如 Logback）输出到控制台或文件时未配置
charset属性。
为什么改了 -Dfile.encoding 还乱码？
常见原因不是参数没生效，而是影响范围被高估或存在其他干扰项：
- IDE（如 IDEA）自身终端/控制台使用的是操作系统代码页（Windows 默认 GBK），和 JVM 的
file.encoding是两套体系； - Tomcat 等容器可能通过
catalina.sh或JAVA_OPTS覆盖了启动参数； - 环境变量
JAVA_TOOL_OPTIONS会自动注入 JVM 参数，优先级高且不易察觉； - 文件本身是 UTF-8 带 BOM，但 JVM 用 GBK 解析，或反过来——
file.encoding只管“怎么解”，不管“原始是什么”； - Spring Boot 的
application.properties中若配置了server.servlet.encoding.charset=UTF-8，仅影响 HTTP 请求体，与文件读写无关。
怎么验证是否真由 file.encoding 导致？
做一次最小闭环测试：
- 写一个含中文的纯文本文件（如
test.txt），用记事本另存为 UTF-8（无 BOM）和 GBK 各一份； - 用
Files.readString(Paths.get("test.txt"))（Java 11+）读取，不传 Charset； - 分别启动：
java -Dfile.encoding=UTF-8 Test→ 应正确读 UTF-8 文件，乱码 GBK 文件；java -Dfile.encoding=GBK Test→ 应正确读 GBK 文件，乱码 UTF-8 文件。
结果符合预期，就说明 file.encoding 正在按预期工作；不符，则需检查文件实际编码、IDE 终端设置或是否存在隐式覆盖。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
