保存乱码即字节已损坏，必须立即停止保存并回退；VSCode中应先用Reopen with Encoding试探编码，再用Save with Encoding正确保存；配置语言级encoding或项目级settings.json可预防，files.autoGuessEncoding建议关闭。
保存后中文乱码，基本等于文件内容被永久破坏了——不是显示问题，是字节已写错。这时候再改编辑器设置已经晚了，必须立刻停止保存操作，回退或修复字节。
看到乱码第一反应：别按 Ctrl+S
这是最常踩的坑。VSCode 打开一个 GBK 编码的 .txt 或 .java 文件，显示“锟斤拷”，你下意识按 Ctrl+S，它就会用当前 files.encoding（默认 UTF-8）把那些乱码字符重新编码写回磁盘。原始 GBK 字节彻底丢失，救不回来。
- 只要状态栏显示的编码和文件真实编码不一致，就别点保存
- 不确定时，先点状态栏编码 → 选
Reopen with Encoding→ 试 GBK / GB2312 / UTF-8-with-BOM，看哪一种能还原出正常中文 - 确认正确编码后，再点
Save with Encoding，强制以该编码保存
Save with Encoding 和 Reopen with Encoding 的区别
这两个操作在状态栏点击后都出现，但作用完全不同，混用必出事：
-
Reopen with Encoding：只改变当前打开方式，不写磁盘，安全试探 -
Save with Encoding：用指定编码重写整个文件，覆盖原内容，危险动作 - 比如你用 GBK 正确打开了文件，但状态栏仍显示 UTF-8，这时点
Save with Encoding→ UTF-8，就等于把正确的中文又转成乱码存了一遍
如何避免下次再保存错
靠每次手动点状态栏不可靠，尤其批量处理老项目时。得让 VSCode 记住“这类文件该用什么编码”：
- 在
settings.json中加语言级配置，例如 Java 文件默认用 GBK："files.associations": { "*.java": "java" }, "files.encoding": "utf8", "[java]": { "files.encoding": "gbk" } - 对单个项目，可在项目根目录建
.vscode/settings.json，写死"files.encoding": "gbk"，优先级高于全局 - 慎用
files.autoGuessEncoding：它在纯中文短文件上极容易猜错，建议设为false
如果已经保存错了，还能抢救吗
能，但前提是原始文件没被覆盖多次。关键看是否还留有未关闭的 tab：
- 如果乱码文件 tab 还开着，且没关过、没重启过 VSCode，可以右键 tab →
Revert and Close，恢复到上次磁盘状态（即保存前） - 如果已关闭，检查系统回收站或 Git 历史：
git status看是否被 commit 过，git checkout HEAD~1 -- file.java拉回上一版 - 实在没备份，可用
iconv逆向尝试：iconv -f utf8 -t gbk broken.java > fixed.java，但成功率取决于乱码程度
真正难处理的，是那种“先乱码→保存→再用 Notepad++ 改完又保存”的混合操作，字节被反复错误编码，基本无解。所以所有补救手段，都不如养成“先确认编码再保存”的肌肉记忆。
