VSCode乱码应先点击右下角编码名选“Reopen with Encoding”尝试GBK/GB2312等编码临时恢复显示，确认正常后再用“Save with Encoding”转为UTF-8保存，避免误操作覆盖原文件。
点击右下角编码显示，选“Reopen with Encoding”
看到满屏“锟斤拷”或“文件”时，第一反应不是改设置，而是先让当前文件正确显示。VSCode 右下角状态栏的 UTF-8（或其他编码名）就是入口——直接点击它，菜单里选 Reopen with Encoding，再挑 GBK、GB2312 或 GBK (with BOM)。这个操作只影响当前文件的内存解码，不写磁盘，安全。
注意几个细节：
- 如果选完还是乱码，别急着再点别的编码，先检查是否误点了
Save with Encoding——那个会直接覆盖原文件，把乱码字节存成新编码，原始中文就真丢了 -
GBK和GB2312在多数中文 Windows 文件上效果一样，但遇到生僻字时GBK更稳妥 - 某些带 BOM 的 UTF-8 文件，状态栏可能显示
UTF-8 with BOM，这种一般不用动；但如果显示的是纯UTF-8却乱码，反而要试试GBK
用命令面板搜“Change File Encoding”，避免手动翻列表
状态栏菜单滚动找编码很慢，尤其当列表里几十项时。Ctrl + Shift + P（macOS 是 Cmd + Shift + P）打开命令面板，直接输入 Change File Encoding，回车后弹出的选项和状态栏一致，但支持关键词过滤：比如输 gbk，列表立刻聚焦到 GBK 项，按回车就能重开。
这个方式更适合批量处理多个乱码文件：
- 每次只对当前活动标签页生效，切标签前记得先保存或确认编码
- 命令面板里选
Save with Encoding后，VSCode 会用新编码把当前内容写回磁盘——这步必须确认内容已正确显示，否则等于二次破坏 - 如果文件是 Git 跟踪的，
Save with Encoding后git diff会显示大量字节变化，这是正常现象，说明编码真的改了
files.autoGuessEncoding 设为 true，但别全信它
VSCode 的自动猜测机制在 settings.json 里由 "files.autoGuessEncoding": true 控制。开启后，它会根据 BOM、字节分布、常见中文字符模式尝试判断，对中等长度的 GBK 文件有一定成功率。
但它有明显局限：
- 纯英文+少量中文注释的文件，容易被误判为 UTF-8
- 空行多、注释少的配置文件（如
.properties），猜测失败率很高 - 一旦猜错并执行了保存，原始编码信息就丢失了，后续更难还原
所以建议：仅对新项目或明确统一编码的团队仓库开启；老项目、混合编码的目录下，宁可手动指定，也不要依赖自动猜测。
终端输出乱码和文件编码是两回事
改完文件编码，发现集成终端里 python main.py 输出还是“”或方块？这不是 files.encoding 没设对，而是终端本身的编码环境问题。
Windows 上最常见的情况：
- PowerShell 或 CMD 默认代码页是
GBK（即936），但 Python 解释器启动时可能按系统 locale 读取为 UTF-8，导致输出错位 - 解决方案是加环境变量：
PYTHONIOENCODING=utf-8，或者在终端里先执行chcp 65001切换到 UTF-8 代码页 - VSCode 设置里的
terminal.integrated.env.windows可以全局注入该变量，避免每次手动设
关键点在于：编辑器里文件能正常看，不代表终端能正常输出。这两条链路完全独立，排查时必须分开验证。
文件编码问题最麻烦的从来不是“怎么改”，而是“改完要不要保存”“保存时用哪个编码”“改了这个文件，其他同目录文件会不会连锁乱码”。尤其是老项目里混着 UTF-8、GBK、甚至 GB18030 的情况，一个 Save with Encoding 操作就可能让协作同事第二天拉代码时全崩。动手前，先用 file -i filename（Linux/macOS）或 PowerShell Get-Content -Encoding Byte（Windows）粗略看下原始字节特征，比瞎猜靠谱得多。
