先确认文件真实编码，vscode右下角“utf-8”仅表示当前解析方式而非实际编码；若为gbk文件被误解析，会导致中文显示方块或问号，应通过reopen with encoding临时修复并另存为utf-8。
右下角显示“UTF-8”但中文是方块或问号？先确认真实编码
VSCode 状态栏显示的编码只是当前**解析方式**，不是文件真实编码。Windows 记事本另存为“ANSI”、旧 Java .properties 文件、Python 2 日志，大概率是 GBK 编码，却被 VSCode 当作 UTF-8 解析——结果就是“你好”变成 或空白方块。
快速验证方法：
- 点击右下角
UTF-8→ 选Reopen with Encoding→ 看菜单里是否高亮GBK或GB2312（常排在前几位） - Linux/macOS 终端执行：
file -i your-file.js；Windows 可用certutil -hashfile your.py SHA256结合已知编码指纹比对 - 十六进制查看前几字节：
xxd your.py | head -n 2—— 若出现c4 e3 ba c3（“你好”的 GBK 字节），就不是 UTF-8
单次打开乱码文件：用“Reopen with Encoding”临时修复
这是最安全、无副作用的操作，不改文件内容，只换解析方式。
- 打开乱码文件，确保焦点在编辑器内
- 点击右下角当前编码标识（如
UTF-8、GBK或灰色的Auto） - 在弹出菜单中选择
Reopen with Encoding→ 再选GBK、GB2312或ISO-8859-1（试到能读为止） - 能正常显示后，立刻点
File → Save As，在保存对话框底部选UTF-8编码另存为新文件
注意：不要直接 Save，否则会把 GBK 字节按 UTF-8 编码覆写，导致永久损坏。
让新文件默认用 UTF-8，避免反复踩坑
全局配置能减少后续干扰，但不能解决已有乱码文件——它只影响新建和自动猜测行为。
打开 settings.json（命令面板输入 Preferences: Open Settings (JSON)），添加或修正以下三项：
{
"files.encoding": "utf8",
"files.autoGuessEncoding": true,
"files.encodingSave": "utf8"
}
-
files.encoding：新建文件、未带 BOM 的文件默认用 UTF-8 解析 -
files.autoGuessEncoding：遇到无 BOM 文件时，主动尝试 GBK/UTF-8 等多种编码匹配（开启后右下角可能显示灰色Auto） -
files.encodingSave：强制保存为 UTF-8，杜绝“另存为时手滑选错”
这项配置对 Git 项目尤其关键：若 .gitattributes 未声明 * text=auto eol=lf，不同系统提交的 GBK 文件可能在协作中持续引发乱码。
终端输出中文还是乱码？那是另一套编码链
编辑器里中文正常 ≠ 终端里中文正常。集成终端（Terminal）和调试控制台（Debug Console）完全不读 editor.fontFamily 和 files.encoding，它们走的是操作系统级字符流通道。
- Windows 用户：在
settings.json中加这段，让 PowerShell/CMD 启动时切到 UTF-8
"terminal.integrated.profiles.windows": {
"PowerShell": {
"source": "PowerShell",
"args": ["-NoExit", "/c", "chcp 65001"]
}
},
"terminal.integrated.defaultProfile.windows": "PowerShell"
- Linux/macOS 用户：确保 shell 配置文件（
~/.bashrc或~/.zshrc）末尾有
export LANG=zh_CN.UTF-8 export LC_ALL=zh_CN.UTF-8
改完记得 source ~/.zshrc 并彻底重启 VSCode（仅 reload 不生效）。
真正容易被忽略的是：终端乱码往往和字体无关，而是 LANG 环境变量没生效，或 shell profile 被 VSCode 启动方式绕过（比如从桌面图标启动时未加载 .zshrc）。先查 echo $LANG，再调字体。
