文件开头带 BOM 时，TextDecoder 会怎么处理？ignoreBOM 是什么意思？

默认和 ignoreBOM: true 的对比

在字母 A 前面加上 UTF-8 的 BOM，用两种选项分别解码。

const bytes = new Uint8Array([0xef, 0xbb, 0xbf, 0x41]) // BOM + 'A'

const normal = new TextDecoder('utf-8').decode(bytes)
const kept = new TextDecoder('utf-8', { ignoreBOM: true }).decode(bytes)

console.log(normal, normal.length) // A 1，BOM 被去掉了
console.log(kept.length) // 2，BOM 还在
console.log(kept.codePointAt(0).toString(16)) // feff

BOM 在实际项目里怎么坑人

UTF-8 其实不需要 BOM，因为它按单字节读，没有字节序的问题。BOM 原本是为 UTF-16 设计的，用来区分大端和小端。但 Windows 上的一些工具保存 UTF-8 文件时会带上它，最典型的就是 Excel。

带 BOM 的 JSON 解析失败

有时候 JSON.parse 读一个配置文件，报 Unexpected token，打开文件看又完全正常，很可能就是开头有 BOM。fetch 的 res.json() 和 res.text() 内部会去掉 UTF-8 BOM，不会有问题。但用 Node 的 fs.readFileSync(path, 'utf8') 读文件时，BOM 会保留在字符串开头，JSON.parse 碰到 \uFEFF 就报错。这时要么检查 str.charCodeAt(0) === 0xfeff 后去掉第一个字符，要么用 TextDecoder 默认选项解码。

导出 CSV 时反而要加 BOM

反过来，前端导出 CSV 给用户用 Excel 打开时，如果不加 BOM，Excel 会按系统默认编码去读，中文全变乱码。常见做法是在内容前拼一个 '\uFEFF' 再生成 Blob。这就是 BOM 现在最主要的用途：给不支持编码声明的老软件一个提示。

分块解码要复用同一个 decoder

读大文件或流式响应时，数据是一块一块来的，要用 decoder.decode(chunk, { stream: true }) 并且始终用同一个 TextDecoder 实例。它会记住自己是否已经过了流的开头，只在第一块检查 BOM，也能正确处理被切断在两块之间的多字节字符。每块都 new 一个新的 decoder，被切断的中文字符会变成乱码。

容易答错的地方

以为 ignoreBOM: true 会删掉 BOM

正好相反。默认 false 才会跳过 BOM，设成 true 是关闭这层特殊处理，BOM 会留在结果里。需要 BOM 原样保留的场景很少，比如要把文本原封不动写回文件。

对整个字符串全局替换 \uFEFF

BOM 只在开头才有编码标记的含义。正文里出现的 U+FEFF 历史上用作零宽不换行空格，可能是有意放的。要去 BOM，只处理第一个字符，别用 replace(/\uFEFF/g, '') 全删。

面试官还会怎么问？

把知识连起来