在HTML中，&标记引用的开始，无论是字符引用还是实体引用。从那时起，解析器期望一个表示字符引用的#，或者一个表示实体引用的实体名称，两者后跟一个;。这是正常的行为。

但如果引用名或引用开头的&后面跟着空格或其他分隔符，如"，'，<，>，&，则结尾;甚至一个表示普通符号的引用&也可以省略:

<p title="&amp;">foo &amp; bar</p>
<p title="&amp">foo &amp bar</p>
<p title="&">foo & bar</p>

只有在这些情况下，才能结束;或者甚至引用本身被省略(至少在HTML 4中)。我认为HTML 5需要结尾;。

但是规范建议总是使用字符引用&#38;或者实体引用&为了避免混淆:

作者应该使用“&”(ASCII十进制38)而不是“&”，以避免与字符引用(实体引用打开分隔符)的开头混淆。作者还应该在属性值中使用“&”，因为CDATA属性值中允许使用字符引用。

如果你说的是静态文本

<title>Foo & Bar</title>

存储在硬盘上的某个文件中并直接由服务器提供，那么是的:它可能不需要转义。

然而，由于现在很少有HTML内容是完全静态的，我将添加以下免责声明，假设HTML内容是从其他来源生成的(数据库内容、用户输入、web服务调用结果、遗留API结果，……):

如果你不转义一个简单的&，那么很可能你也不转义&或a &nbsp;或<b>或<script src="http://attacker.com/evil.js">或任何其他无效文本。这意味着您最多只能错误地显示您的内容，并且更有可能受到XSS攻击。

换句话说:当您已经检查和转义其他更有问题的情况时，那么几乎没有理由留下没有完全损坏但仍然有点可疑的独立&未转义的情况。

这取决于分号在&附近结束的可能性，导致它显示完全不同的内容。

例如，当处理来自用户的输入时(例如，如果在标题标签中包含用户提供的论坛帖子的主题)，您永远不知道他们可能会在哪里放置随机分号，并且可能会随机显示奇怪的实体。所以在这种情况下一定要逃避。

当然，对于您自己的静态HTML内容，您可以跳过它，但是包含适当的转义太琐碎了，因此没有理由避免它。

更新(2020年3月):W3C验证器不再抱怨转义url。

我正在检查为什么图像url需要转义，因此在https://validator.w3.org中尝试了它。这个解释很好。它强调了即使是url也需要转义。[PS:我猜它将无法转义当它被消费，因为url需要&。有人能澄清一下吗?］

<img alt="" src="foo?bar=qut&qux=fop" />

An entity reference was found in the document, but there is no reference by that name defined. Often this is caused by misspelling the reference name, unencoded ampersands, or by leaving off the trailing semicolon (;). The most common cause of this error is unencoded ampersands in URLs as described by the WDG in "Ampersands in URLs". Entity references start with an ampersand (&) and end with a semicolon (;). If you want to use a literal ampersand in your document you must encode it as "&" (even inside URLs!). Be careful to end entity references with a semicolon or your entity reference may get interpreted in connection with the following text. Also keep in mind that named entity references are case-sensitive; &Aelig; and æ are different characters. If this error appears in some markup generated by PHP's session handling code, this article has explanations and solutions to your problem.

是的，如果可能的话，您应该尝试提供有效的代码。

大多数浏览器会无声地纠正这个错误，但是依赖浏览器中的错误处理存在一个问题。对于如何处理不正确的代码没有标准，因此每个浏览器供应商都要尝试找出如何处理每个错误，结果可能会有所不同。

一些浏览器可能会有不同反应的例子是，如果你把元素放在表格中，但在表格单元格之外，或者你把链接嵌套在彼此之间。

对于您的特定示例，它不太可能导致任何问题，但是浏览器中的错误更正可能会导致浏览器从标准兼容模式变为怪癖模式，这可能会使您的布局完全崩溃。

因此，您应该在代码中纠正这样的错误，如果没有其他错误，则可以使验证器中的错误列表保持简短，以便您可以发现更严重的问题。

如果用户将它传递给您，或者它将在URL中结束，您需要转义它。

如果它以静态文本的形式出现在页面上?所有浏览器都能正确地处理这个问题，您不必太担心，因为它可以工作。