乱码是VSCode用错编码读取文件所致，如GBK文件被当UTF-8打开；未保存前点击右下角编码按钮选择正确编码（如GBK）可恢复显示，再保存为UTF-8以确保跨平台兼容。
乱码不是文件坏了，而是VSCode用错了编码去读它——最常见的是GBK文件被当UTF-8打开，注释里的中文直接变成“锟斤拷”或“文件”。救回来的前提是：还没按Ctrl+S保存过。
点击右下角编码按钮重新打开文件
这是最快、最安全的临时修复方式。VSCode窗口右下角状态栏会显示当前编码（如UTF-8），直接点击它，选择Reopen with Encoding → GBK（或GB2312）。注意：
- 这个操作只改内存解码方式，不写磁盘，不会破坏原始字节
- 如果选错编码，比如对UTF-8文件强行选GBK，会看到更奇怪的乱码，换回来就行
- Windows上老项目、Java源文件、批处理脚本里中文注释，优先试
GBK；Mac/Linux上一般不用动
确认并统一保存编码为UTF-8
长期协作和跨平台开发，必须让文件真正存成UTF-8。在正确解码显示中文后，点击状态栏编码区域，这次选Save with Encoding → UTF-8。关键点：
- 不要选
UTF-8 with BOM——BOM（EF BB BF）在Python、Node.js等场景可能引发语法错误 - 保存后，状态栏应稳定显示
UTF-8，且中文注释清晰可读 - 如果保存时报错“无法写入”，说明文件被其他进程占用（如IDEA、记事本正开着），关掉再试
全局默认编码设为UTF-8，但别关自动猜测
避免每次打开都手动切，进设置搜files.encoding，设为utf8；同时确保files.autoGuessEncoding保持true。原因：
- 设
utf8能让新文件、新建文件默认用UTF-8，减少后续麻烦 - 留着自动猜测，VSCode遇到带BOM的UTF-8或明显是GBK特征的旧文件，仍有机会自己识别
- 关掉自动猜测后，所有非UTF-8文件都会强制乱码，排查成本反而更高
终端输出中文乱码？那是另一回事
代码注释显示正常，但运行时console.log('中文')或print('中文')在集成终端里还是乱码？这不是文件编码问题，是终端环境没配UTF-8：
- Windows PowerShell：启动时加一行
[Console]::OutputEncoding=[System.Text.UTF8Encoding]::new()，或运行chcp 65001 - Windows CMD：同样用
chcp 65001，但需注意某些旧版CMD不完全支持 - Git Bash / WSL：检查
locale输出是否含UTF-8，不是就改export LANG=en_US.UTF-8 - VSCode设置里
terminal.integrated.defaultProfile.windows若指向CMD，建议换成PowerShell
真正容易被忽略的是：乱码分“能救”和“已毁”。你看到乱码还只是“显示错”，一旦点了Ctrl+S，VSCode就用当前编码（比如UTF-8）把那些乱码字符重新编码写回磁盘——原始GBK字节彻底覆盖，再也找不回来了。所以，第一反应永远是停手、右键状态栏、选Reopen with Encoding，而不是先去改设置。
