HTML实体字符是防止页面崩坏、内容错乱和XSS攻击的关键防线，必须对、&、"、'等有语法意义的字符转义，而UTF-8可支持中文、emoji直输但不替代语法转义。
HTML实体字符不是“可有可无的语法糖”，而是防止页面崩、内容错、代码被执行的关键防线。不处理，轻则版权符号©变成乱码，重则用户输入的直接注入执行。
为什么必须转义才能显示为文本
浏览器解析HTML时，遇到，中间所有内容被当作标签名、属性或注释处理。一旦没闭合或嵌套错，后续DOM结构全乱。
- 错误现象：
<h1>标题</h1>写成<h1>标题</h1>→ 页面真渲染出一级标题，原始代码消失 - 真实场景：文档教程、代码高亮块、API返回的HTML片段预览，都依赖
和<code>>原样呈现 - 安全影响：若后端把用户评论
<img src="https://img.php.cn/" alt="HTML实体字符在开发中的重要性">直接插入页面，未转义 = XSS漏洞
哪些符号必须用实体，哪些可以靠UTF-8直输
是否需要实体，取决于字符是否“在HTML中有保留含义”或“键盘/编码环境不保证稳定输出”。UTF-8声明（<meta charset="UTF-8">）能解决大部分中文、emoji显示，但挡不住<code>&"这类语法字符。
- 必须用实体：
、<code>>、&、"、'—— 它们参与HTML解析，逃不掉 - 推荐用实体：
©、®、™、€—— 键盘难输、字体fallback时更稳 - 可直输但需谨慎：中文标点、emoji、数学符号 —— 依赖页面声明UTF-8且编辑器保存编码一致，否则.git diff里全是问号
不只是“多打个空格”，它控制断行与对齐
本质是Unicode U+00A0，一个视觉像空格但语义上“不可分割”的字符。普通空格会被浏览器折叠、换行， 不会。
Wechat Article Html
下载
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
立即学习“前端免费学习笔记（深入）”；
- 典型误用：用多个
text-align或grid - 合理用途：中英文混排时防断行（如
JavaScript API）、金额数字分隔（¥ 1,299）、表单占位（<option value=""> </option>） - 性能注意：大量
后端模板和前端JS里，实体处理位置很关键
实体转义不是“写一次就完事”，它必须发生在数据进入HTML上下文的**最后一道环节**。提前转义或漏转义，都会出问题。
- 后端模板（如Django/Jinja）：默认
{{ user_input }}自动转义，要显式{{ user_input|safe }}才不转 —— 别盲目加|safe - 前端JS拼接HTML：绝对避免
el.innerHTML = '<div>' + userInput + '</div>'；改用el.textContent = userInput或document.createTextNode() - 框架例外：React/Vue默认转义插值内容，但
v-html或dangerouslySetInnerHTML绕过转义 —— 此时你得自己确保输入已净化
最常被忽略的一点：实体只在HTML解析阶段起作用。一旦DOM构建完成，©在textContent里就是普通字符串©，再不会二次解析。所以服务端返回JSON里的"title": "© 2026"，前端用el.textContent赋值是安全的；但用el.innerHTML就等于又走了一遍HTML解析，风险重现。
