直接用编辑器输出的HTML渲染网页会出问题，因其为编辑行为服务而非语义化/SEO/跨设备设计，含嵌套标签、空元素、残留属性、冗余样式甚至非法标签，导致解析异常、CSS失效、移动端错乱；必须经DOM克隆白名单过滤和DOMPurify安全兜底两道清洗，并辅以服务端校验与降级fallback。
为什么直接用编辑器输出的 HTML 渲染网页会出问题
富文本编辑器生成的 HTML 天然不适合直接作为网页源码：它不是为语义化、SEO 或跨设备渲染设计的，而是为编辑行为服务的。常见表现是 <p> 嵌套 <div>、空 <span>、残留 data-mce-* 属性、style="font-size:12px" 冗余内联样式，甚至出现 <meta> 被意外插入到 <body> 里——这些都会让浏览器解析异常、CSS 重置失效、移动端布局错乱。
contenteditable 输出必须过两道清洗关
无论你用的是 Quill、TinyMCE 还是自研 contenteditable，原始输出都不能直出。必须分步清洗：
- 第一道：DOM 克隆 + 白名单过滤 —— 不要读
innerHTML，先cloneNode(true)，再遍历移除所有非白名单标签（只留p、h1-h6、ul、ol、li、strong、em、a、img）、非白名单属性（删掉所有class、style、data-*、id） - 第二道：DOMPurify 安全兜底 —— 即使你认为已清理干净，仍要调用
DOMPurify.sanitize(html, { ALLOWED_TAGS: [...] })，否则 XSS 漏洞可能来自零宽字符或注释中隐藏的<script> - 特别注意：
<br>和<div>在段落末尾的残留行为不一致，建议统一用<p>包裹纯文本，用<pre>包裹代码块，禁止<div>作段落容器
TinyMCE / CKEditor 5 输出 HTML 的容错配置要点
如果你没自己写清洗逻辑，得靠编辑器自身配置把脏 HTML 拦在源头：
- TinyMCE：必须设
valid_elements（如"p,strong,em,a[href],img[src|alt]"），禁用extended_valid_elements除非明确需要自定义标签；forced_root_block: "p"强制换行生成<p>而非<div> - CKEditor 5：启用
htmlSupport插件时，必须配allow: [{ name: /.*/, attributes: true, classes: true, styles: true }]—— 否则默认只放行极简标签；但更推荐关闭该插件，改用editor.data.get({ trim: 'both' })获取净化后内容 - 两者都禁用
paste_as_text: false（即不允许纯文本粘贴），因为用户复制 Word 时若走纯文本路径，会丢掉列表、链接等结构信息
HTML 文档结构容错的最后防线：服务端校验与 fallback
前端清洗只是第一层，真正可靠的容错发生在服务端：
立即学习“前端免费学习笔记（深入）”；
- 入库前用 Cheerio 或 jsdom 解析 HTML，检查是否含非法根节点（比如
<html>或<head>出现在内容里）、是否缺失<p>包裹纯文本、是否有孤立<img>（无src或alt） - 渲染时加 wrapper 容器并强制 CSS 重置：
<article class="rich-content">...</article>，配套 CSS 里写.rich-content * { all: unset; }再逐个声明需要的样式，避免继承污染 - 对不可控字段（如用户提交的「简介」）始终准备 fallback：当 HTML 校验失败时，自动降级为
textContent渲染，而不是报错或空白
真正的容错不是让 HTML 看起来“差不多”，而是确保它在任意浏览器、任意设备、任意后续处理环节里，都能被当成一段安全、可预测、可维护的文档结构来对待。清洗不是附加步骤，是数据流入系统的必经闸口。
