将BOM放在UTF-8编码的文件中至少有三个问题。

不包含文本的文件不再为空，因为它们始终包含BOM。 在UTF-8的ASCII子集中保存文本的文件本身不再是ASCII，因为BOM不是ASCII，这使得一些现有工具无法使用，用户可能不可能替换这些遗留工具。 不可能将几个文件连接在一起，因为现在每个文件开头都有一个BOM。

而且，正如其他人所提到的，使用BOM来检测某些东西是否是UTF-8是既不够也没有必要的:

这是不够的，因为任意字节序列可能恰好以构成BOM的确切序列开始。 这是不必要的，因为你可以像读取UTF-8一样读取字节;如果成功，根据定义，它是有效的UTF-8。

如上所述，带有BOM的UTF-8可能会导致非BOM感知(或兼容)软件出现问题。我曾经用基于mozilla的KompoZer编辑UTF-8 + BOM编码的HTML文件，因为客户需要WYSIWYG程序。

保存时，布局总是会被破坏。我花了一些时间来解决这个问题。这些文件在Firefox中运行良好，但在Internet Explorer中显示了一个CSS怪癖，再次破坏了布局。在摆弄了几个小时链接的CSS文件后，我发现Internet Explorer不喜欢BOMfed HTML文件。我再也不会见你了。

还有，我刚在维基百科上找到了这个:

The shebang characters are represented by the same two bytes in extended ASCII encodings, including UTF-8, which is commonly used for scripts and other text files on current Unix-like systems. However, UTF-8 files may begin with the optional byte order mark (BOM); if the "exec" function specifically detects the bytes 0x23 0x21, then the presence of the BOM (0xEF 0xBB 0xBF) before the shebang will prevent the script interpreter from being executed. Some authorities recommend against using the byte order mark in POSIX (Unix-like) scripts,[15] for this reason and for wider interoperability and philosophical concerns

BOM倾向于在某个地方爆炸(没有双关语)。当它突然出现时(例如，无法被浏览器、编辑器等识别)，它会以奇怪的字符出现在文档的开头(例如，HTML文件、JSON响应、RSS等)，并导致类似于最近奥巴马在Twitter上谈话时经历的编码问题那样的尴尬。

当它出现在难以调试的地方或当测试被忽略时，这是非常令人讨厌的。所以除非必须使用，否则最好避免使用。

Unicode字节顺序标记(BOM)常见问题解答提供了一个简明的答案:

Q: How I should deal with BOMs? A: Here are some guidelines to follow: A particular protocol (e.g. Microsoft conventions for .txt files) may require use of the BOM on certain Unicode data streams, such as files. When you need to conform to such a protocol, use a BOM. Some protocols allow optional BOMs in the case of untagged text. In those cases, Where a text data stream is known to be plain text, but of unknown encoding, BOM can be used as a signature. If there is no BOM, the encoding could be anything. Where a text data stream is known to be plain Unicode text (but not which endian), then BOM can be used as a signature. If there is no BOM, the text should be interpreted as big-endian. Some byte oriented protocols expect ASCII characters at the beginning of a file. If UTF-8 is used with these protocols, use of the BOM as encoding form signature should be avoided. Where the precise type of the data stream is known (e.g. Unicode big-endian or Unicode little-endian), the BOM should not be used. In particular, whenever a data stream is declared to be UTF-16BE, UTF-16LE, UTF-32BE or UTF-32LE a BOM must not be used.

其他优秀的回答已经回答过了

UTF-8和BOM-ed的UTF-8之间没有官方的区别 一个BOM-ed的UTF-8字符串将以以下三个字节开始。Ef bb bf 如果存在这些字节，在从文件/流中提取字符串时必须忽略。

但是，作为附加信息，UTF-8的BOM可以很好地“嗅出”字符串是否以UTF-8编码……或者它可以是任何其他编码的合法字符串…

例如，数据[EF BB BF 41 42 43]可以是:

合法的ISO-8859-1字符串“ABC” 合法的UTF-8字符串“ABC”

因此，尽管通过查看第一个字节来识别文件内容的编码很酷，但您不应该依赖于此，如上面的示例所示

编码应该是已知的，而不是推测的。

一个实际的区别是，如果你为Mac OS X编写一个shell脚本，并将其保存为普通的UTF-8，你将得到响应:

#!/bin/bash: No such file or directory

在shebang行指定您希望使用哪个shell的响应中:

#!/bin/bash

如果你保存为UTF-8，没有BOM(说在BBEdit)，一切都会很好。