先用reopen with encoding确认原编码是gbk，再用save with encoding选utf-8保存；顺序颠倒会导致文件永久损坏。
直接告诉你结论：先用 Reopen with Encoding 确认原编码是 GBK，再用 Save with Encoding 选 UTF-8 保存——顺序错了就真把文件搞坏了。
为什么不能直接点右下角选 UTF-8 就完事？
VSCode 右下角点击后弹出的菜单里，“Reopen with Encoding”和“Save with Encoding”是两件完全不同的事：
-
Reopen with Encoding：只改当前编辑器怎么读这个文件，不碰磁盘上一个字节。适合诊断——比如点它 → 选GBK，中文出来了，说明文件确实是 GBK 编码 -
Save with Encoding：把编辑器里现在看到的内容（注意：是“现在看到的”，不是原始字节），按你选的编码（如UTF-8）重新写回硬盘。这才是真正转码，文件内容永久改变 - 常见错误：乱码时直接点右下角 → 选
UTF-8（没选“Reopen”），结果满屏方块——那是 VSCode 强行用 UTF-8 解释 GBK 字节，属于错解，不是切换
怎么确认文件真是 GBK 编码？
别靠猜。Windows 下老项目、.txt/.java/.jsp/.properties 文件，大概率是 GBK；但得验证：
- 先点右下角编码名 →
Reopen with Encoding→ 依次试GBK、GB2312、GBK (codepage 936)，能正常显示中文的就是真实编码 - 如果试完都乱，可能是
UTF-8 with BOM被误判，或文件本身已被错误保存过（比如之前乱码时按了 Ctrl+S） - 终端里用
file -i filename（Linux/macOS）或enca -L zh filename（需安装 enca）可辅助判断，但 VSCode 自带功能已够用
保存成 UTF-8 时要注意什么？
确认是 GBK 后，下一步才是转码，但细节决定成败：
- 确保编辑器里中文显示正常（即已用 GBK 正确打开），再点右下角 →
Save with Encoding→ 选UTF-8（不是UTF-8 with BOM） - 选
UTF-8 with BOM容易导致 Python/Node.js 脚本报错，Java 编译器也可能跳过 BOM 导致注释解析异常 - 保存后右下角会变成
UTF-8，再关掉重开，确认仍能正常显示——这才是转成功了 - 如果转完再打开还是乱，大概率是上次乱码时已经误保存过一次，原始 GBK 字节被覆盖，无法恢复
批量转换别信 VSCode 插件
VSCode 没有真正可靠的批量转码能力。所谓“一键转所有”的插件，本质是循环执行 Reopen + Save，一旦某个文件识别失败，就静默损坏：
- Windows 用户推荐 PowerShell +
iconv：Get-ChildItem *.java | ForEach-Object { iconv -f GBK -t UTF-8 $_.FullName | Set-Content "$($_.DirectoryName)\$($_.BaseName)_utf8$($_.Extension)" -Encoding UTF8 } - macOS/Linux 直接用：
find . -name "*.txt" -exec iconv -f GBK -t UTF-8 {} -o {}.utf8 \; - 操作前务必备份原目录，混合编码项目要先分批扫描再处理
最危险的一步永远是第一次按 Ctrl+S——看到乱码时，手千万别快。先确认编码，再决定要不要保存。很多文件救不回来，不是因为技术不行，而是那一下回车按得太早。
