VSCode清除BOM需执行“Save with Encoding → UTF-8”而非“Reopen”，并必须同时配置"files.encoding":"utf8"和"files.autoGuessEncoding":false，否则BOM会复发。
VSCode 本身不提供“一键清理 BOM 字符”的独立命令，但能通过明确的编码重存操作清除文件开头的 \uFEFF（即字节 EF BB BF）。关键不是“怎么找”，而是“怎么安全删”——因为 BOM 是不可见字节，误操作可能损坏内容或换行符。
右下角显示“UTF-8 with BOM”时，如何真正清除它
点击右下角编码名称 → 选 Save with Encoding → 选 UTF-8（注意：不是 UTF-8 with BOM）。
- 这个动作会重写整个文件，跳过开头三个 BOM 字节，其他内容一字不变
- 如果菜单里没有
UTF-8选项，只看到UTF-8 with BOM，说明 VSCode 认为当前内容“必须靠 BOM 才能正确解码”，常见于曾被 GBK 打开、含中文且未声明编码的文件；此时先按Ctrl+S保存一次，再点右下角重试 -
Reopen with Encoding → UTF-8不起作用——它只是用 UTF-8 规则重新解释磁盘上已有的字节，BOM 还在文件里
为什么改了设置，新文件还是带 BOM
根本原因在于 files.autoGuessEncoding 没关，或者被插件/项目配置覆盖。
- 必须同时设两项：
"files.encoding": "utf8"（小写、无连字符、无 bom 后缀）和"files.autoGuessEncoding": false - 检查工作区级
.vscode/settings.json，它优先级高于全局设置，常被忽略 - 某些插件（如 EditorConfig）会在
.editorconfig里写charset = utf-8-bom，删掉或注释掉这一行 - 临时验证：禁用所有插件后新建文件测试，确认是否还带 BOM
批量清理已有文件的 BOM（Linux/macOS/WSL）
别信“一键转码”类插件——它们本质是循环 reopen + save，中间任意一步识别错，文件就损坏。用底层工具更稳。
- 单个文件：
sed -i '1s/^\xEF\xBB\xBF//' file.js - 递归处理所有
.js和.json：find . \( -name "*.js" -o -name "*.json" \) -exec sed -i '1s/^\xEF\xBB\xBF//' {} \; - 验证是否成功：
head -c 3 file.js | xxd，输出应为空或非ef bb bf - Windows 用户可用 Notepad++ 批量转存，但之后务必确认 VSCode 的
files.autoGuessEncoding是false，否则下次保存又悄悄加回去
Node.js 读取 JSON 报 SyntaxError: Unexpected token \uFEFF 怎么办
这不是编辑器问题没解决，而是代码没兜底——BOM 可能来自协作方、CI 构建产物或旧系统导出，不能只靠编辑器预防。
- 服务端读取时手动清除：
fs.readFileSync('./config.json', 'utf8').replace(/^\uFEFF/, '') - 更稳妥做法是读成
Buffer再解码：Buffer.from(fs.readFileSync('./config.json')).toString('utf8').replace(/^\uFEFF/, '') - ESM 环境下
import不支持 JSON，必须 fs 读取，此时 BOM 清除不能省 - 如果用
require('./config.json')，CommonJS 内部已处理 BOM，但仅限纯 JSON 文件（不能含注释、尾逗号）
BOM 是三个字节，不是字符；它不占光标位置，也看不到，但 Node、Python、Git 全都认它。最麻烦的不是删不掉，而是删完忘了关 autoGuessEncoding，或者没检查 .editorconfig ——前功尽弃只在一念之间。
