VSCode不支持安全批量编码转换，因其批量操作实为循环执行Reopen/Save with Encoding，易因误判无BOM的GBK等编码导致静默损坏；必须先用file/enca/iconv或Python+chardet确认真实编码再转换。
VSCode 本身不支持安全、可靠的批量编码转换，所谓“批量”操作本质是循环执行 Reopen with Encoding + Save with Encoding，极易因误判原始编码导致内容静默损坏。
为什么不能直接用 VSCode 批量转码
VSCode 的状态栏操作（如点击右下角 → Save with Encoding）只作用于当前已打开的单个文件；它没有内置机制扫描目录、识别真实编码、逐个重读重写。插件宣称的“批量”，底层仍是模拟人工点击，但无法解决两个致命问题：
- 对无 BOM 的 GBK/GB2312 文件，VSCode 常误判为
ISO-8859-1或windows1252，Reopen with Encoding选错就直接显示乱码，且无 Undo - 一个项目里可能混着 GBK、BIG5、UTF-8 with BOM、纯 ASCII —— 统一指定“转成 UTF-8”会把原本就是 UTF-8 的文件二次解码，产生
\ufffd替换符 - 已打开的文件会缓存上次使用的编码，改了
files.encoding也无效，必须手动重开
先确认真实编码，再用命令行批量处理
安全的前提是知道“哪些文件真是 GBK”。别跳过这步，否则转完才发现部分文件变砖，只能靠备份回滚。
- Linux/macOS：
file -i *.js *.html *.py，看输出是否含charset=gbk；macOS 可追加enca -L zh filename辅助验证 - Windows PowerShell：
Get-Content -Path .\a.js -Encoding Byte | Select-Object -First 4，比对常见 GBK 字节头（如CE D2、B9 FA），UTF-8 BOM 是EF BB BF - 确认后，用
iconv批量转换：iconv -f GBK -t UTF-8 input.js -o output.js；验证无误再mv output.js input.js - 若需跨平台或更灵活控制（比如跳过二进制文件、按扩展名过滤），用 Python 脚本更稳：
chardet检测原始编码，open(..., encoding='utf-8')写入即为无 BOM UTF-8
VSCode 配置只管“怎么读/怎么存”，不管“怎么改旧文件”
设置 files.encoding 和 files.autoGuessEncoding 是为了规范后续行为，不是清洗历史数据的工具：
-
"files.encoding": "utf8"（注意小写，不是UTF-8）让新文件默认 UTF-8；写入时不会加 BOM - 项目级生效：把该配置放进项目根目录的
.vscode/settings.json，避免污染全局 -
"files.autoGuessEncoding": false必须关掉——它对中文编码基本无效，反而增加误判概率 - 已有 GBK 文件不会因此自动变 UTF-8，它们仍按上次打开时记的编码加载；必须手动点一次
Save with Encoding→UTF-8，VSCode 才会记住这个偏好
BOM 是最容易被忽略的兼容性雷区
转完 UTF-8 后，别急着提交。BOM 的存在与否直接影响编译器和解释器：
- 选
UTF-8（无 BOM）：Node.js、Python、现代 C++ 编译器首选；但 Windows 记事本打开会显示空白行 - 选
UTF-8 with BOM：记事本友好，但 Python 脚本开头若带\xff\xfe会直接报SyntaxError；MSVC 编译 C++ 文件可能触发warning C4819 - VSCode 默认保存就是无 BOM；只有显式点
Save with Encoding→UTF-8 with BOM才会写入三字节头 - 团队协作强烈推荐统一用无 BOM UTF-8，并在
.editorconfig中固化：charset = utf-8
