vscode乱码是读取编码错误而非文件损坏，应先右下角点击编码名选“reopen with encoding”→gbk验证真实编码，确认正常后“save with encoding”→utf-8转码覆写，并配置"files.autoguessencoding": false、语言专属"encoding"及编译器参数确保链路一致。
VSCode乱码不是文件坏了，而是它“读错了”字节——你得告诉它用什么规则去解码，而不是让它猜。
右下角点击“UTF-8”后该选哪个编码？
别凭名字瞎选。Windows 下老项目、记事本保存的 .java/.c/.txt 文件，90% 是 GBK，不是 GB2312 或 UTF-8 with BOM。直接点状态栏编码 → 选 Reopen with Encoding → 滚动找到并选 GBK。如果中文立刻正常显示，说明猜对了；如果更乱，就换一个再试。
常见误操作：
- 看到
UTF-8 with BOM就手滑点进去 → Java 编译器可能忍，但 Maven 和 Git diff 会报Illegal character或冒出\ufeff - 乱码状态下直接点
Save with Encoding→ 把已错解的乱码内容按新编码写回磁盘，乱码就固化了 - 选完编码没反应？检查是否在编辑未保存的临时文件（如剪贴板粘贴生成的 untitled-1），这类文件不关联磁盘路径，重开无效
settings.json 里必须加的三行配置
只改全局 files.encoding 没用。老文件不会自动转，新建文件也不影响已有乱码。真正起效的是这三项组合：
-
"files.autoGuessEncoding": false—— 关掉自动猜测，否则 VSCode 可能在你编辑时悄悄用GBK重载老文件，你根本不知道 -
"[java]": { "files.encoding": "utf8" }—— 给.java文件单独指定，比全局设置更精准（其他语言同理，比如"[cpp]": { "files.encoding": "utf8" }） -
"java.configuration.compilerArgs": ["-encoding", "UTF-8"]—— 强制javac用 UTF-8 解码源码，否则即使文件是 UTF-8，编译器也可能按系统默认GBK去读
注意："files.encoding": "utf8" 只影响新建空文件，对已存在的乱码文件完全无效。
终端输出还是 ?????？和编辑器设置无关
你在 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.shellArgs.windows": ["/K chcp 65001 >nul"]（配合字体如Lucida Console）
为什么改完还是乱？关键在“链路”没对齐
乱码常发生在三条链路上，缺一不可：
- 文件保存编码 vs VSCode 打开编码（靠右下角重开或配置
files.encoding） - 源码编码 vs 编译器读取编码（靠
compilerArgs或命令行-encoding） - 程序输出字节 vs 终端解码方式（靠
JAVA_TOOL_OPTIONS或chcp）
最容易被忽略的是：你改了编辑器，但忘了改编译器；或者终端设了 UTF-8，JVM 却还用系统默认 GBK 输出。只要其中一环是 GBK，整条链就断了。
