富文本编辑器粘贴崩样式因直接插入未清洗的杂乱html；应启用粘贴过滤或手动拦截清洗。获取html需用编辑器api或克隆+白名单处理。存数据优先选delta/markdown等结构化格式，非原始html。
富文本编辑器为什么总在粘贴时崩样式？
因为绝大多数富文本编辑器（比如 quill、tinymce、ckeditor5）默认把粘贴内容当作“带格式的 HTML”直接插入，而用户从 Word、微信、网页复制过来的 HTML 往往嵌套深、含内联 style、有冗余 span 和 font 标签，甚至带不可见控制字符。编辑器没做清洗，就直接渲染或存库，后续解析、搜索、SEO、移动端适配全受影响。
实操建议：
- 启用编辑器内置的「粘贴过滤」功能：比如
quill配置clipboard: { matchVisual: false }关闭视觉匹配，强制走纯文本降级；tinymce设置paste_as_text: true或用paste_preprocess钩子手动清理 - 自己写粘贴拦截：监听
paste事件，用event.clipboardData.getData('text/html')拿原始 HTML，再用 DOMParser + 白名单标签/属性过滤（只留p、strong、ul、li、href等），最后insertHTML进编辑区 - 别依赖「粘贴后手动删样式」——用户不会，测试也容易漏
contenteditable 元素里如何安全获取结构化 HTML？
直接读 innerHTML 是最常见也最危险的做法：它会暴露浏览器自动补全的标签（比如把孤立 <li> 包进 <ul></ul>）、保留编辑残留（如 data-mce-* 、class="Apple-style-span"）、甚至混入不可见的 ZWSP（零宽空格）导致后端解析失败。
实操建议：
- 优先用编辑器提供的导出 API：比如
quill.getSemanticHTML()（需插件）、ckeditor5的editor.data.get({ trim: 'both' })，它们已做过语义归一 - 若必须手撸，先克隆节点：
const clone = el.cloneNode(true)，再遍历移除所有非白名单属性（class、style、data-*等），最后用clone.innerHTML - 对输出 HTML 做二次校验：用
DOMPurify.sanitize(html, { ALLOWED_TAGS: [...] })防 XSS，别跳过这步
服务端存富文本，该存 HTML 还是 Markdown？
存 HTML 表面省事，实际埋雷最多：不同编辑器生成的 HTML 差异大（<strong></strong> vs <b></b>）、浏览器解析行为不一致（特别是自闭合标签）、后续想换编辑器几乎无法平滑迁移。
实操建议：
- 新项目一律存结构化中间格式：比如
quill的Delta对象（JSON）、lexical的EditorState序列化结果，前端渲染时再转 HTML —— 存的是意图，不是表现 - 若必须存文本，选 Markdown：用
remark+rehype生态统一解析/序列化，配合自定义插件支持表格、代码块等扩展，比 HTML 更可控 - 已有 HTML 库想改造？别全量重存。加个字段存原始 Delta/Markdown 备份，新编辑走新格式，老数据按需转换
移动端富文本输入卡顿、光标错位怎么办？
根本原因是 contenteditable 在 iOS Safari 和部分安卓 WebView 中对长段落、嵌套列表、实时协作光标等场景支持极差，加上频繁触发 input 事件和 DOM 更新，很容易掉帧甚至崩溃。
实操建议：
- 禁用原生输入法的自动更正和预测：给编辑容器加
spellcheck="false" autocorrect="off" autocomplete="off" - 限制最大段落数和单段长度：监听
input，用el.innerText.length做软截断，提示用户「内容过长，请分段提交」 - 关键交互延迟更新：比如撤销/重做、协作光标，改用
requestIdleCallback批量处理，避免阻塞主线程 - 真遇到光标乱跳？检查是否用了
white-space: pre-wrap或word-break: break-all—— 这些 CSS 在移动端会干扰光标定位逻辑
富文本不是「把 HTML 存进去再吐出来」这么简单。真正难的，是让不同来源的内容、不同终端的输入、不同版本的编辑器，在同一套语义规则下稳定协作。很多问题看似是编辑器配置不对，其实是没想清楚：你到底要保存「用户写了什么」，还是「用户想表达什么」。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
