vscode保存utf-8文件带bom是因默认encoding在中文windows下回退至utf8bom，导致node.js/python报错及前端解析失败；应设files.encoding为utf8并禁用trimtrailingwhitespace防自动保存时“复活”bom。
VSCode保存UTF-8文件时为什么总带BOM
因为VSCode默认的files.encoding在某些场景下会回退到utf8bom——尤其是你用中文Windows系统打开一个没声明编码的旧文件，或者从剪贴板粘贴内容后首次保存。BOM本身是三个字节EF BB BF，对Node.js、Python等环境可能触发UnicodeDecodeError或SyntaxError: Invalid or unexpected token，前端加载JS/CSS时也可能报解析错误。
这不是bug，是VSCode对“向后兼容旧Windows工具”的妥协。但现代开发基本不需要它。
- 检查当前文件编码：右下角状态栏点击
UTF-8（或UTF-8 with BOM），选Save with Encoding→UTF-8 - 这个操作只改当前文件，不改变默认行为
- 如果状态栏显示
UTF-8 with BOM，说明该文件已含BOM，直接另存为UTF-8会清除它
全局禁用BOM：修改settings.json里的files.encoding
VSCode不会自动把files.encoding设成utf8，除非你明确指定。很多人只改了用户设置，却忘了工作区设置会覆盖它。
- 打开设置（
Ctrl+,），搜files.encoding，把下拉值改成utf8（不是utf8bom） - 更可靠的方式是直接编辑
settings.json，加入："files.encoding": "utf8"
- 如果项目根目录有
.vscode/settings.json，它优先级高于用户设置，务必检查是否被覆盖 - 注意：该设置只影响新创建/新打开的文件；已有BOM的文件不会自动剥离，需手动另存
自动保存时仍出现BOM？检查files.autoSave和files.trimTrailingWhitespace
看似无关的两个配置组合起来会“复活”BOM：当files.autoSave设为afterDelay或onFocusChange，且文件原本带BOM，VSCode会在自动保存时保留原始编码——哪怕你设置了files.encoding: "utf8"。
- 确认
files.autoSave值不是off（否则手动保存时才生效） - 更关键的是：
files.trimTrailingWhitespace启用时，VSCode有时会误判编码并重写为utf8bom，尤其在混合换行符（CRLF/LF）的文件中 - 临时验证方法：关掉
files.trimTrailingWhitespace，再试一次自动保存 - 终极方案：加一条
"files.autoSave": "onWindowChange"，避免编辑中途触发编码混淆
脚本批量清理已有BOM文件（Windows/macOS/Linux通用）
设置只能管未来，老项目里几十个带BOM的.js、.json、.md文件还得手动处理。别用Notepad++批量另存——容易错乱换行符或损坏二进制内容。
- 推荐用
iconv命令行（macOS/Linux自带，Windows需装libiconv或用Git Bash）：iconv -f UTF-8 -t UTF-8//IGNORE file.js | sed '1s/^\xEF\xBB\xBF//' > file_clean.js
- 更稳妥的Node.js小脚本（保存为
strip-bom.js）：const fs = require('fs'); const f = process.argv[2]; let d = fs.readFileSync(f); if (d[0]===0xEF && d[1]===0xBB && d[2]===0xBF) d = d.slice(3); fs.writeFileSync(f, d);然后运行node strip-bom.js src/index.js - 注意：不要对
.png、.jpg等二进制文件执行此操作，会直接损坏
settings.json，且CI流程里加一步校验——比如用file --mime-encoding扫出带BOM的文本文件并报错。
