VSCode右下角显示的编码仅为当前解码方案，并非文件真实编码；应点击右下角→Reopen with Encoding依次试GBK、GB2312、UTF-8 with BOM、UTF-8，中文立即正常即确认真实编码，该操作不修改磁盘文件。
右下角编码标识只是“VSCode以为的”，不是文件真实编码
VSCode 状态栏右下角显示的 UTF-8 或 GBK，只是它当前用来解码文件的编码方案，不等于文件磁盘上实际保存的编码。很多用户误以为点开就看到“真实编码”，结果按这个去保存，反而把原本正常的 GBK 文件用 UTF-8 覆盖写坏。
真正验证真实编码的唯一安全方式，是手动尝试不同编码重新加载——只要中文立刻变正常，且无错位、无方块、无“锟斤拷”，基本就是对的。
用 Reopen with Encoding 逐个试，优先试这四个
点击右下角编码名（比如显示 UTF-8），弹出菜单后选 Reopen with Encoding，然后依次尝试：
-
GBK—— Windows 记事本、老旧配置文件、国内导出的 CSV 最常见 -
GB2312—— 部分老系统或网页表单提交的文本 -
UTF-8 with BOM—— Excel、Notepad++ 默认导出的 CSV/文本常带 BOM -
UTF-8—— 新项目、Git 仓库、跨平台协作的标准
注意：这个操作不改磁盘文件，纯内存重解码，关掉再重开也不会丢内容。只要一试就恢复正常，就停手——别继续往下试。
全试完还乱码？可能是混合编码或已损坏
如果上述四种都试过，中文仍显示异常（如部分正常、部分乱、有空格错位、出现 符号），说明文件可能：
- 本身是混合编码（比如前几行 GBK，后面 UTF-8）——极难自动修复，建议复制可读内容到新文件，另存为
UTF-8 - 含不可见控制字符（如
\x00、\xff\xfe）——VSCode 会直接判定为二进制，状态栏甚至不显示编码标识 - 已被错误保存覆盖过一次（比如之前乱码时按了 Ctrl+S）——原始字节已丢失，无法回退
此时可装官方 Hex Editor 插件，直接看文件开头几个字节：若以 EF BB BF 开头，就是 UTF-8 with BOM；若以 FF FE 开头，是 UTF-16 LE；若开头是中文对应 GBK 字节（如 D6 D0 对应“中”），那就是 GBK。
为什么 autoGuessEncoding 开了还是猜不准
files.autoGuessEncoding: true 是有用，但不是万能的。它的原理是扫描字节特征+统计概率，对以下情况容易失效：
- 文件太短（
- 纯中文无标点、无 ASCII 字符，GBK 和 UTF-8 的字节分布相似度高
- 文件含大量注释或日志格式（如
[INFO] 中文），干扰检测逻辑
所以别依赖它“自动搞定”。把它当辅助，而不是主力。日常开发中，团队统一用 UTF-8 并禁用猜测（"files.autoGuessEncoding": false），反而更稳定——前提是所有文件真用 UTF-8 保存了。
最常被忽略的一点：确认编码 ≠ 解决问题。能看到正常中文，只是第一步；必须紧接着用 Save with Encoding → UTF-8 才算真正转码成功。否则下次打开，VSCode 还会按旧规则加载。
