直接写 & 会导致 HTML 解析错误，因为解析器将其视为实体开头，若后续无合法实体名或分号（如  ），会引发截断、乱码或 XML 解析错误；正确写法是统一使用 &。

为什么直接写 & 会导致 HTML 解析错误

HTML 解析器遇到未转义的 & 会尝试将其识别为字符实体（如 &、<）的开头。如果后面没跟合法的实体名或分号，就会报错或截断内容——比如 &nbsp 缺少分号，浏览器可能忽略或报 XML Parsing Error。

正确使用 & 实体显示 & 符号

唯一可靠的方式是用标准 AMP 实体 &。它在所有 HTML 版本（HTML4、XHTML、HTML5）中都有效，且不会被误解析。

Article To Html

文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。

下载

• ✅ 正确：& → 渲染为 &
• ❌ 错误：&（无转义）、&amp（缺分号）、&（虽能显示但可读性差，不推荐）
• 在属性值中也要转义，例如：<a href="https://www.php.cn/link/31b7dbebefaf552b556cb54e164f94c5">link</a>

在不同上下文中要注意的细节

模板引擎、Markdown、JS 字符串里写 & 的行为不一致，容易漏转：

• 纯 HTML 文件：必须写 &，不能依赖编辑器自动替换
• Vue / React 模板中：JSX 里属性值仍需 &，但插值表达式（如 {text}）若变量含原始 &，需提前在 JS 层转义
• Markdown 渲染器（如 GitHub README）：部分支持 &，但有些会二次解析，稳妥起见仍用 &
• 生成 HTML 的脚本（Python 的 html.escape()、JS 的 DOMPurify.sanitize()）：它们默认处理 &，但注意是否开启 allowElements 等选项影响结果

常见错误现象和快速验证方法

页面出现乱码、链接跳转失败、W3C 验证报 character reference "&" is not defined，基本都是 & 转义遗漏或不完整。

• 用浏览器开发者工具「Elements」面板查看源码，确认是否真渲染出 & 字符串，而非原始 &
• 在 URL 查询参数中混用 & 和 &（如 ?a=1&b=2&c=3）会导致后端只收到 a=1，因为第一个未转义 & 被当成参数分隔符
• 服务端返回的 HTML 若由字符串拼接生成，务必对用户输入调用转义函数，不能只靠前端过滤

实际写的时候，别想着“这里应该没问题”，只要文本里有 &，就无条件替换成 &——这是最省心的底线规则。