vscode java乱码必须四层编码全对齐：源文件读取、编译器解析、终端输出、插件宿主，缺一不可；需先用reopen with encoding确认真实编码（如gbk），再配置files.autoguessencoding:false、[java]:{files.encoding:"utf8"}、java.configuration.compilerargs:["-encoding","utf-8"]及terminal.integrated.env.windows中java_tool_options。
VSCode 乱码不是配错，是配不全——settings.json里只加一两行根本没用，必须覆盖「文件读取」「编译器解析」「终端输出」「插件宿主」四层编码链路，缺一不可。
确认真实编码再改配置，别瞎猜
右下角显示 UTF-8 但中文是方块？先别动 settings.json。点右下角编码标识 → 选 Reopen with Encoding → 尝试 GBK（不是 GB2312）。如果中文立刻恢复，说明磁盘里存的就是 GBK，后续所有配置都要围绕这个事实展开。
- 误选错编码后直接点
Save with Encoding，会把已解错的乱码内容以新编码写回磁盘，原始中文永久丢失 -
UTF-8 with BOM看似安全，但javac虽能忍，git diff会报Illegal character，Maven构建可能失败 - 用记事本保存过的
.java文件，99% 是GBK，别信右下角默认显示
Java 项目必须加这三行，少一行都不行
"files.encoding": "utf8" 只影响新建空文件，对已有乱码文件完全无效；"files.autoGuessEncoding": false 才是关键——关掉自动猜测，否则 VSCode 编辑时会悄悄用 GBK 重载老文件，你根本不知道。
-
"[java]": { "files.encoding": "utf8" }：给.java文件单独指定，比全局设置更精准 -
"java.configuration.compilerArgs": ["-encoding", "UTF-8"]：强制javac用UTF-8解码源码，否则即使文件是UTF-8，编译器也可能按系统默认GBK去读 - 这三项必须同时存在，漏掉
compilerArgs，System.out.println("你好")编译就报错
终端输出乱码和编辑器设置无关
你在编辑器里把文件全设成 UTF-8，运行后控制台还是 ????，这不是编辑器问题，是 Windows 终端代码页（chcp 返回 936）和 JVM 输出编码没对齐。
- 在
settings.json中加："terminal.integrated.env.windows": { "JAVA_TOOL_OPTIONS": "-Dfile.encoding=UTF-8" } - 该配置让 JVM 强制用
UTF-8编码输出，VSCode 终端渲染层才不会字节错位 -
chcp 65001是临时方案，重启终端就失效；环境变量才是永久解法 - 注意：这个配置只对 Java 生效，Python 或 C 需额外配
PYTHONIOENCODING=utf8或chcp 65001在执行命令前
Output 面板乱码要动 Node.js 级别
插件日志、语言服务器通信、ESLint 报错等出现在 Output 面板里的中文变成 \u4f60\u597d 或空格，和 files.encoding、terminal.* 全部无关——这是 VSCode 插件宿主进程（基于 Node.js）默认未启用 UTF-8 模式。
-
"files.encoding"对Output面板完全无效 - 必须在系统级环境变量中设置：
NODE_OPTIONS=--experimental-utf8（Node.js ≥18.17+） - 若无法升级 Node.js，可在插件代码中显式调用：
process.stdout.setEncoding('utf8') - JSON 配置文件（如
.eslintrc.json）必须以UTF-8 无 BOM保存，否则保存即崩
最易被忽略的是：同一份配置在不同场景下生效范围完全不同——files.encoding 管打开，compilerArgs 管编译，JAVA_TOOL_OPTIONS 管运行时输出，NODE_OPTIONS 管插件后台。它们互不替代，也不能互相推导。
