直接用编辑器输出的html渲染网页会出问题，因其为编辑行为服务而非语义化/seo/跨设备设计，含嵌套标签、空元素、残留属性、冗余样式甚至非法标签，导致解析异常、css失效、移动端错乱；必须经dom克隆白名单过滤和dompurify安全兜底两道清洗，并辅以服务端校验与降级fallback。
为什么直接用编辑器输出的 HTML 渲染网页会出问题
富文本编辑器生成的 HTML 天然不适合直接作为网页源码：它不是为语义化、SEO 或跨设备渲染设计的，而是为编辑行为服务的。常见表现是 <p></p> 嵌套 <div>、空 <code><span></span>、残留 data-mce-* 属性、style="font-size:12px" 冗余内联样式，甚至出现 <meta> 被意外插入到 里——这些都会让浏览器解析异常、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></script> - 特别注意：
<br>和<div> 在段落末尾的残留行为不一致，建议统一用 <code><p></p>包裹纯文本，用<pre class="brush:php;toolbar:false;"></pre>包裹代码块，禁止<div> 作段落容器<h3>TinyMCE / CKEditor 5 输出 HTML 的容错配置要点</h3> <p>如果你没自己写清洗逻辑，得靠编辑器自身配置把脏 HTML 拦在源头：</p><div class="aritcle_card flexRow artxards"> <div class="artcardd flexRow"> <a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill6712" title="Wechat HTML Publisher"><img src="https://img.php.cn/upload/skill/000/000/081/179109368394970.jpg" alt="Wechat HTML Publisher" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a> <div class="aritcle_card_info flexColumn"> <a rel="nofollow" href="/xiazai/skill6712" title="Wechat HTML Publisher" class="overflowclass">Wechat HTML Publisher</a> <p class="overflowclass">直接上传HTML富文本到微信公众号草稿箱。支持完整的HTML格式,无需Markdown转换。</p> </div> <a rel="nofollow" href="/xiazai/skill6712" title="Wechat HTML Publisher" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span> </a> </div> </div> <ul><li>TinyMCE：必须设 <code>valid_elements（如"p,strong,em,a[href],img[src|alt]"），禁用extended_valid_elements除非明确需要自定义标签；forced_root_block: "p"强制换行生成<p></p>而非<div> <li>CKEditor 5：启用 <code>htmlSupport插件时，必须配allow: [{ name: /.*/, attributes: true, classes: true, styles: true }]—— 否则默认只放行极简标签；但更推荐关闭该插件，改用editor.data.get({ trim: 'both' })获取净化后内容 - 两者都禁用
paste_as_text: false（即不允许纯文本粘贴），因为用户复制 Word 时若走纯文本路径，会丢掉列表、链接等结构信息 - 入库前用 Cheerio 或 jsdom 解析 HTML，检查是否含非法根节点（比如
或出现在内容里）、是否缺失<p></p>包裹纯文本、是否有孤立<img>（无src或alt） - 渲染时加 wrapper 容器并强制 CSS 重置：
<article class="rich-content">...</article>，配套 CSS 里写.rich-content * { all: unset; }再逐个声明需要的样式，避免继承污染 - 对不可控字段（如用户提交的「简介」）始终准备 fallback：当 HTML 校验失败时，自动降级为
textContent渲染，而不是报错或空白
HTML 文档结构容错的最后防线：服务端校验与 fallback
前端清洗只是第一层，真正可靠的容错发生在服务端：
真正的容错不是让 HTML 看起来“差不多”，而是确保它在任意浏览器、任意设备、任意后续处理环节里，都能被当成一段安全、可预测、可维护的文档结构来对待。清洗不是附加步骤，是数据流入系统的必经闸口。
