接收方是 Excel 就带，是程序读就别带。这句话能覆盖九成的选择。BOM 是文件最开头的三个字节（EF BB BF），本身不是内容，只是一个编码声明。它带来的麻烦和好处都来自同一个位置——文件第一位。

带 BOM 解决什么

Windows 上的 Excel 双击打开 CSV 时，会按系统本地编码去猜。简体中文系统上这个默认猜测通常不是 UTF-8，于是中文全变成一堆无规律字符。「CSV转换」里勾选输出带 BOM 的 CSV，就是在开头写入那三个字节，Excel 读到它会明确按 UTF-8 解码，中文正常显示。

这个需求只出现在双击打开这条路径上。通过「数据 → 从文本导入」并手工指定编码的场景不需要 BOM。

还要明确一点：BOM 只占开头三个字节，正文内容一个字都不改。所以带不带它不会让数据变样，来回切换是安全的。真正会让人抓狂的是另一个现象——同一份 CSV 被业务方用 Excel 打开又原样保存几次之后，BOM 可能丢失，也可能叠到第二份，于是这份文件呈现「上周还好好的、这周第一个表头又乱了」。碰到这种时好时坏的乱码，别怀疑编码选错，让对方重新从你这里取一份原始文件，并且改用只读查看的方式。

不带 BOM 又避免什么

程序的读取器多数不认识这三个字节。真实报错表现有三种：第一个列名前面挂着隐形字符，按键名取值取不到；解析出的第一条数据整体错位；逐行处理时首行匹配不上任何预期表头。这些错误在开发环境看不出来，因为写代码的人常把第一列硬编码绕过去了。

还有一个约束必须知道：浏览器端的编码器只能输出 UTF-8。所以想要 GBK 或 ANSI 编码的 CSV，在这个页面拿不到——本站的输出选项只有 UTF-8 与 UTF-8 带 BOM 两种。对方系统硬性要求 GBK 时，只能在下载后用记事本另存为对应编码，或者回到服务端生成。

三分钟做完判断

  1. 问一句：这份文件谁会打开？人 + Excel 还是脚本或数据库导入。
  2. 交给业务方就用 CSV转换 勾选带 BOM 输出，让对方直接双击。
  3. 给程序用就不勾，同时把分隔符固定成逗号，别让自动识别参与。
  4. 两边都要的话出两份，不要指望一份通吃。

别用 BOM 掩盖别的问题

乱码不全是编码声明导致的。源数据本身已经在某一层被错解过（比如从 Excel 另存时选了带 ANSI 的 CSV，再上传解析），这时加 BOM 只会让已经坏掉的字符稳定地显示成另一批怪字。先确认输入文件的真实编码，再决定输出选项。

顺带一提，TXT处理 能自动识别 UTF-8、带 BOM 的 UTF-8 与 GBK/GB18030 三种输入编码，可以先用它的统计项看看字节数对不对得上，判断问题出在哪一层。它同样不支持 UTF-16、Big5 与 EUC-KR。

底线判断：如果一份文件既发给人又发给程序，正确做法是发带 BOM 的那份给人、不带的那份给程序，而不是让程序去兼容 BOM。这个决定不该由工具替你猜。更多细节见 CSV 中文乱码修复。