乱码本质是VSCode用错编码解码文件字节，非文件损坏；必须先“Reopen with Encoding”确认真实编码并正常显示，再“Save with Encoding”转码覆写，顺序颠倒会导致数据永久损坏。
直接说结论：乱码不是转换失败，而是你用错了“打开方式”或“保存动作”。 文件本身字节没变，只是 VSCode 解码时用了错误的编码规则。关键在“先 reopen，再 save”，顺序反了就永久写坏。
看到乱码第一反应：别按 Ctrl+S
很多人一看到“锟斤拷”就下意识保存，结果 VSCode 用当前 encoding（比如 UTF-8）把那些乱码字符重新编码写回磁盘——原始中文字节被覆盖，救不回来。这时候文件已经“写坏了”，不是显示问题，是数据丢失。
- 确认是否已保存：看右上角文件标签是否有 * 号，有说明已修改未保存，还能撤回
- 如果已保存且内容异常，立刻关掉文件，别再打开；用
git checkout或备份恢复原始文件 - 真正安全的操作路径是：
Reopen with Encoding→ 确认内容正常 → 再决定是否Save with Encoding
Reopen with Encoding 选哪个编码？看系统和文件来源
Windows 上老项目、.ini/.bat/.reg 文件、国产软件导出的文本，大概率是 GBK（不是 GB2312，后者是子集，兼容性差）；Linux/macOS 下基本默认 UTF-8；带 BOM 的文件会显示为 UTF-8 with BOM，优先选它。
- 不确定时，从
GBK、GB18030、UTF-8、UTF-8 with BOM这四个里试 - 避免选
ISO-8859-1或Windows 1252，它们不支持中文，选了只会更乱 - 如果文件里混有英文和中文，且英文正常但中文乱，基本可锁定是 GBK/UTF-8 错配
Save with Encoding 后还是乱？检查 files.autoGuessEncoding
VSCode 有个开关叫 files.autoGuessEncoding，默认是 false。但如果你手动改过设置，或者装了某些插件，它可能被设为 true——这时即使你刚用 GBK 正常打开了文件，下次打开仍可能被自动猜成 UTF-8，又变乱码。
- 在命令面板输入
Preferences: Open Settings (JSON)，检查有没有这一行："files.autoGuessEncoding": true - 建议设为
false，靠人工判断更可靠；真要开，也得配合files.encoding设为utf8全局兜底 - 语言级覆盖更稳妥：在 settings.json 里加
"[javascript]": {"files.encoding": "utf8"}，避免全局误伤
终端输出中文还是乱？那是另一套编码链路
编辑器里文件显示正常，但集成终端跑 Python/C++ 输出中文仍是问号或方块，这不是文件编码问题，是终端环境编码不一致。VSCode 终端默认继承系统 shell 的代码页，Windows 上常是 936（GBK），而 Python 默认按 UTF-8 输出。
- 临时修复：在终端里执行
chcp 65001（Windows）或export LANG=en_US.UTF-8（Linux/macOS） - 永久生效：在 VSCode 设置里搜
terminal.integrated.env，添加环境变量PYTHONIOENCODING=utf-8 - 注意：这跟
files.encoding完全无关，调错地方白忙活
最麻烦的其实是“你以为修好了”的情况：文件用 GBK 重新打开后显示正常，你顺手点了 Save with Encoding → 选了 UTF-8 → 内容看着还行，但注释里的中文在 Git diff 里出现 \u4f60\u597d，或者别人拉代码后又乱码。这种隐性损坏，往往要等协作或部署时才暴露。
