java控制台中文乱码的根本原因是javac编译、jvm运行、终端渲染三阶段编码不一致；windows常见链路为源文件utf-8→javac误按gbk读→jvm按utf-8解码→终端按gbk渲染，导致错位解码出现问号或方块。
Java控制台打印中文乱码，根本不是 VSCode “不支持中文”，而是 javac 编译、JVM 运行、终端渲染这三步用的编码不一致，字节流被错位解码了。Windows 下最常见链路是：源文件 UTF-8 → javac 默认按 GBK 读 → 生成 class 文件里存的是 GBK 字节 → JVM 却按 UTF-8 解码 → 终端再按 GBK 渲染，结果就是 ??? 或方块。
怎么确认当前 Java 文件真实编码？
别看右下角状态栏显示什么就信什么。很多老项目 .java 文件本身就是 GBK 编码，VSCode 默认按 UTF-8 打开，一打开就是乱码。这时直接改 settings.json 是白忙活。
- 点击右下角编码标识（如
UTF-8）→ 选 “Reopen with Encoding” → 尝试GBK（不是GB2312，优先试GBK） - 如果中文立刻恢复，说明磁盘里存的就是 GBK，后续要统一转成 UTF-8 或全程用 GBK
- 千万别在乱码状态下点 “Save with Encoding” → 那会把已错解的乱码内容以 UTF-8 写回磁盘，原始中文就永久丢失了
- 看到
UTF-8 with BOM就绕开 → Java 编译器能忍，但Maven和git diff会报Illegal character或冒出\ufeff
必须配齐的三项 Java 编码配置
只设 "files.encoding": "utf8" 没用，它只影响新建空文件保存编码，对已有文件无效。真正起效的是这三项组合，缺一不可：
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
-
"files.autoGuessEncoding": false—— 关掉自动猜测，否则 VSCode 会在你编辑时悄悄用 GBK 重载老文件，你根本不知道 -
"[java]": { "files.encoding": "utf8" }—— 给 .java 文件单独指定，比全局设置更精准 -
"java.configuration.compilerArgs": ["-encoding", "UTF-8"]—— 强制javac用 UTF-8 解码源码，否则即使文件是 UTF-8，编译器也可能按系统默认 GBK 去读
终端输出仍是乱码？那是终端没对齐
你在 VSCode 里把文件全设成 UTF-8，System.out.println("你好") 运行后还是 ????，这不是编辑器问题，是 Windows 终端（CMD/PowerShell）代码页和 JVM 输出编码没对齐。
- 在集成终端里执行
chcp，返回936就说明终端正用 GBK；此时 JVM 默认也用 GBK 输出，但 VSCode 终端渲染层却按 UTF-8 解码 → 字节流错位，必然乱码 - 临时方案：
chcp 65001，但每次新开终端都要输，不治本 - 永久解法：在
settings.json中加"terminal.integrated.env.windows": { "JAVA_TOOL_OPTIONS": "-Dfile.encoding=UTF-8" } - 别漏字体：
"terminal.integrated.fontFamily": "'Sarasa Mono SC', 'Microsoft YaHei'"—— 没中文字体，UTF-8 字节再对也渲染不出来
最容易被忽略的点是：终端乱码和编辑器里文件编码是两件事。很多人调了半天 files.encoding，发现控制台还是乱码，就以为配置失败，其实问题压根不在那儿。另外，vmArgs 必须写在 .vscode/launch.json 的 configuration 里才对调试生效；如果只用 Code Runner，得去 code-runner.executorMap 里手动加参数。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
