最快验证乱码是编码错误而非文件损坏：点击右下角编码名→选Reopen with Encoding，依次试GBK、GB2312、UTF-8 with BOM、UTF-8；确认后选Save with Encoding→UTF-8才真正解决。
右下角点编码名 → 选 Reopen with Encoding 是最快验证方式
乱码不是文件损坏，是 VSCode 用错了编码去读它。关键动作不是改设置，而是先确认真实编码：点击窗口右下角显示的编码名（比如 UTF-8 或 GBK），弹出菜单后优先选 Reopen with Encoding，然后依次试：
-
GBK（Windows 记事本、旧项目配置文件最常见） -
GB2312（部分老系统导出文本） -
UTF-8 with BOM（某些 Excel 或 Notepad++ 导出的 CSV） -
UTF-8（新项目、协作代码的正确归宿）
只要中文立刻变正常，就说明找对了。这个操作不改文件内容，安全可逆；如果越试越乱，关掉文件重开再试，Ctrl+Z 在这里无效。
Save with Encoding → UTF-8 才是真正一劳永逸的操作
确认真实编码后，别停在“能看”就结束——继续点右下角编码名，这次选 Save with Encoding，然后选 UTF-8。这步会把文件内容按 UTF-8 重新写入磁盘，解决后续 Git 提交、跨平台编辑、插件解析等所有衍生问题。
注意：
- 勾选
Don’t show again可避免重复提示 - 如果文件里有特殊控制字符或混合编码，保存前建议先复制内容到新文件再另存，防止转码污染
- 不要对
.py、.js等代码文件长期依赖GBK，语法关键字和注释混用时极易出错
files.autoGuessEncoding 设为 false 才更稳
VSCode 默认关闭自动猜编码，但很多人会打开它想“省事”。实际在中文场景下，files.autoGuessEncoding 误判率很高：短文本、纯数字+中文组合、无 BOM 的 GBK 文件，基本都识别成 ISO-8859-1 或 windows1252，导致刚打开就乱码。
正确做法是手动关掉：
- 打开命令面板
Ctrl+Shift+P→ 输入Preferences: Open Settings (JSON) - 加一行：
"files.autoGuessEncoding": false - 保存即生效，无需重启
关掉之后，VSCode 完全依赖你设的 files.encoding 或文件自带 BOM，行为可预期，不会中途突然变乱。
字体配置不对，即使编码全对也会显示方块
编辑器里文字能读，但终端、注释、或某些符号显示为方块/问号？那大概率是字体链没配好。VSCode 的编辑器字体和集成终端字体是两套独立配置，都要显式指定中文字体。
例如 macOS 上推荐这样填：
-
editor.fontFamily设为'SF Mono', 'PingFang SC', 'Hiragino Sans GB', monospace' -
terminal.integrated.fontFamily设为'MesloLGS NF', 'PingFang SC', monospace'（需提前安装 MesloLGS NF 字体）
Windows 用户注意：Microsoft YaHei 要写英文名，不能写“微软雅黑”；Linux 用户推荐 Noto Sans CJK SC。所有字体名之间用英文逗号+空格分隔，末尾保留 monospace 保底。
真正容易被忽略的是：文件编码、字体、Git 路径三者互不干扰，各自要单独处理。一个乱码问题背后，可能同时涉及右下角编码切换、settings.json 配置、终端字体安装、甚至 git config --global core.quotepath false —— 别指望一个开关解决全部。
