应点击“reopen with encoding”而非“save with encoding”，前者仅更改内存解码方式，不修改磁盘文件；后者会用当前乱码内容覆写原始字节，导致中文永久丢失。
右下角状态栏点击编码后选错选项，文件反而更乱
看到“UTF-8”就点“Reopen with Encoding” → 选GBK → 文件正常了，这是对的；但很多人误点“Save with Encoding”，结果用当前乱码内容+新编码写回磁盘，原始中文彻底丢失。关键区别：Reopen with Encoding只改内存解码方式，不碰磁盘；Save with Encoding会真实覆写文件字节。
操作前务必确认：当前显示的中文是“解码错”（能还原）还是“已保存错”（不可逆）。只要没按过Ctrl+S或点过Save with Encoding，基本可救。
- 先别保存，哪怕只是想“试一下”
- 右键文件标签 → 选
Reopen with Encoding，不是Save with Encoding - 中文编码优先试
GBK、GB2312、UTF-8 with BOM，别一上来就翻到列表底部找冷门编码
改了files.encoding全局设置，新文件不乱，旧文件还是乱
files.encoding只影响**新创建文件**的默认保存编码，对已存在的文件无作用。旧文件打开时仍按它自己的BOM或历史编码解析，VSCode不会因为全局设成GBK，就自动用GBK去读一个没BOM的UTF-8老文件。
真正起作用的是files.autoGuessEncoding——它控制VSCode是否尝试从字节特征猜编码。Windows上建议设为true，但别依赖它100%准确，尤其短文本、纯中文段落容易猜错。
- 旧文件必须手动
Reopen with Encoding一次，之后VSCode会记住该路径的偏好编码 - 如果团队共用项目，可在项目根目录加
.vscode/settings.json，写入"files.encoding": "GBK"，比全局设置更精准 -
files.encoding设成utf8或utf8bom会影响新建文件是否带BOM，而BOM本身是双刃剑：VSCode认得，但某些Linux脚本/Python解释器会把它当非法字符报错
PowerShell终端中文输出还是乱码，和文件编码无关
VSCode集成终端的中文乱码，和编辑器里打开的.py或.txt文件编码完全独立。它取决于PowerShell进程自身的[Console]::OutputEncoding、Windows代码页、以及VSCode终端启动参数三者是否统一。
最简验证法：在终端里直接运行chcp，看返回是不是65001（UTF-8代码页）。如果不是，说明终端底层没切过去，改编辑器设置没用。
- 临时修复：终端里运行
chcp 65001，立刻生效但重启即失效 - 永久修复：往
$PROFILE里加$OutputEncoding = [Console]::OutputEncoding = [System.Text.Encoding]::UTF8 - VSCode配置要同步加
"terminal.integrated.profiles.windows"，确保每次启动终端都带chcp 65001命令，否则PowerShell可能沿用系统默认代码页（如936）
插件自动检测编码经常不准，什么时候该信它
像Auto Encode这类插件本质还是基于字节统计做概率判断，对混合编码、含大量ASCII符号的中文文本（比如日志、配置片段），准确率骤降。它适合批量处理未知来源的小文件，但不适合抢救关键源码。
真正可靠的线索永远在文件本身：开头有EF BB BF字节？那是UTF-8 BOM；出现CE D2 C3 C7这种两两成对的高位字节？极大概率是GBK；全是3F 3F 3F（问号）？说明之前已被错误编码覆盖过至少一次。
- 别让插件自动
Save with Encoding，只让它提示“疑似GBK”，你来决定是否Reopen - 用
xxd或Notepad++的“转为Hex显示”看真实字节，比猜快十倍 - 如果文件来自Windows旧系统、国产数据库导出、或某款特定编辑器，直接查该工具默认编码，比瞎猜高效得多
Save with Encoding那一秒的误操作——它把可逆问题变成不可逆灾难。盯紧状态栏弹出菜单里的两个选项文字，比背一百个编码名更重要。
