VSCode中文乱码主因是编码识别错误，应先用右下角“Reopen with Encoding”尝试GBK/GB2312/UTF-8 with BOM验证，再“Save with Encoding→UTF-8”真正修复；终端乱码需chcp 65001、PYTHONIOENCODING及终端配置协同解决。
VSCode 读取文本时中文显示异常，基本可以断定是编码识别错了——不是文件坏了，也不是字体问题，而是编辑器用 UTF-8 去解码了一个实际为 GBK（或 GB2312、Big5）的文件。直接改 settings.json 硬设全局编码，反而会让老项目 .bat 执行失败、Git 日志变成 \u4f60\u597d。
右下角点编码名 → Reopen with Encoding 是唯一安全验证方式
别急着改设置、装插件或重存文件。VSCode 右下角显示的 UTF-8 或 GBK 只是它“猜的”，未必准确。
- 点击右下角编码标识（比如
UTF-8），选Reopen with Encoding - 依次试
GBK（Windows 记事本默认）、GB2312（部分导出配置）、UTF-8 with BOM（Excel/Notepad++ 导出 CSV 常见） - 只要中文立刻变正常，就说明找对了；这个操作不改文件字节，安全可逆
- 如果全试完仍乱码，可能是混合编码或含不可见控制字符，建议复制内容到新文件再另存为
UTF-8
Save with Encoding → UTF-8 才算真正修复
能看 ≠ 已修复。只靠 Reopen with Encoding 是临时解码，下次打开还可能乱——必须把文件内容真正转成通用编码。
- 确认显示正常后，再次点击右下角编码名，选
Save with Encoding→UTF-8 - 注意：必须选
UTF-8，不是UTF-8 with BOM；后者在 Python/Shell 脚本里可能引发SyntaxError: Non-UTF-8 code starting with '\xff' - 保存后 Git diff 会显示完整变更，协作时其他人也不用再手动切编码
- 若文件含特殊符号或注释混用，建议先粘贴到新文件再操作，避免转码污染原始结构
settings.json 配置必须分层、精准、小写
"files.encoding": "utf8" 这行设置看似简单，但加错位置、写错大小写、或没关自动猜测，都会让前面所有操作白费。
-
"utf8"必须全小写；写成"UTF-8"或"UTF8"，VSCode 直接忽略该设置 - 新项目/协作开发：在用户级
settings.json加两行："files.encoding": "utf8"和"files.autoGuessEncoding": false（关掉自动猜测，它对 GBK 基本必错） - 老项目混 GBK 文件：在工作区根目录的
.vscode/settings.json里配："files.associations": {"*.txt": "gbk", "*.ini": "gbk", "*.log": "gbk"}，精准控制后缀，不影响其他类型 - 语言专属规则（如强制
.py用 UTF-8）：用命令面板Preferences: Configure Language Specific Settings→ 选python→ 填"files.encoding": "utf8"
终端输出乱码和文件读取乱码是两回事
文件显示正常 ≠ 终端输出正常。这是 shell 层面的编码对不上：Python 按 UTF-8 输出，cmd/powershell 默认用 GBK 接收，字就糊了。
- Windows 用户：在用户级
settings.json加这段，让终端启动时自动切到 UTF-8 页："terminal.integrated.profiles.windows": {"PowerShell": {"args": ["-NoExit", "-Command", "chcp 65001"]}} - 同时加环境变量：
PYTHONIOENCODING=UTF-8（系统环境变量里设，或在launch.json的env字段中指定） - 注意：
chcp 65001只对当前终端生效；如果用 Code Runner 插件运行 C/Python，需在code-runner.executorMap对应语言命令前加chcp 65001 &&
最常被忽略的是：Reopen with Encoding 只改读法，Save with Encoding 才改文件本身；而终端乱码从来不在编辑器编码设置里解决——它得靠 chcp、PYTHONIOENCODING 和终端 profile 三层配合。三者漏一，中文照样糊。
