先给结论：给人用 Excel 双击打开，就带 BOM；给程序或 Linux 侧工具读，就不带。这两条要求天然相反，所以不存在一个通用答案。BOM 本身不神秘，它是文件最前面那三个不属于任何内容的标记字节（UTF-8 下是 EF BB BF），作用是告诉读取方「后面按 UTF-8 解释」。

它解决的是历史遗留问题

早年 Windows 中文环境里，记事本和 Excel 默认按系统本地编码 GBK 去猜文本文件。UTF-8 的中文字节被当成 GBK 拆读，就变成「鍒涘缓」这一类怪字。开头放一个 BOM，Excel 就不用猜了，直接按 UTF-8 走。而 Linux、macOS 以及绝大多数编程语言的标准库本来就按 UTF-8 处理，BOM 对它们没有任何提示价值，反而是三个多余字符。

理解这一点，后面所有选择都能推出来：BOM 是一个「请按 UTF-8 读我」的自我介绍，只有需要自我介绍的读者才用它。会自我判断的读者，反而会被这段介绍绊一下。

三种真实报错表现

一是 Excel 双击全是乱码：文件是无 BOM 的 UTF-8，Excel 按 GBK 读了。内容没坏，别在乱码状态下保存。

二是程序报找不到字段：导入模板第一列叫「姓名」，你的表头看着一模一样却总匹配失败。因为程序读到的是「看不见的BOM + 姓名」，字段名首多出一段。症状只出现在第一列，这是判定 BOM 最快的方法：第二列往后都正常，只有最左边那一格对不上，基本就是它。

三是第一行内容莫名少一个字或开头多个符号：某些脚本把 BOM 当成第一个数据值的一部分，导致排序、比对时首行永远对不上。表格软件里做去重时会看到「明明重复却删不掉」，也是这个成因。

站内两个工具怎么给

「TXT处理」与 「CSV转换」的输出编码只有两档：UTF-8 与 UTF-8 带 BOM。浏览器编码器只能输出 UTF-8，所以想要 GBK 得下载后再用记事本另存一次。输入侧则宽松得多，TXT 处理会自动识别 UTF-8、UTF-8 带 BOM 和 GBK/GB18030。CSV 转换勾选输出带 BOM 时，就是在文件开头写入那三个字节。

一次选对的判断顺序

  1. 问接收方是人还是程序。人开 Excel → 带 BOM；程序解析 → 不带。
  2. 不确定就先不带。乱码肉眼看得见、一秒钟就能改；字段名里的隐形字符往往要到导入报错才发现。
  3. 拿一份三行的样例先发过去确认，别等整批被打回来。
  4. 在文件名或消息里写清编码，这行字的价值高于任何转换技巧。

底线判断

不要为了迁就某一方，把同一份数据长期存成两种编码的文件。两份并存，迟早有人改了旧的那份。BOM 也不该被当成万能药：如果对方系统硬性要求 GBK，带 BOM 的 UTF-8 一样进不去，必须走记事本转 ANSI。还有一个反向陷阱 —— 不要在乱码状态下直接编辑保存，那时内存里已经是错字符，写回去会覆盖掉原始字节，从此再也修不回来。