为什么你的富文本摘要面试题总做不好？问题出在这里

富文本编辑器的核心实现原理是什么?

富文本编辑器的核心基于浏览器提供的 contenteditable="true" 属性，使一个 DOM 元素(通常是

)变为可编辑区域。用户的所有输入、格式操作最终都会反映在该元素的 DOM 树中，编辑器通过监听 input、keydown、paste 等事件来捕获用户行为，并将 DOM 变化转化为结构化的数据(HTML 字符串或自定义数据模型)。

现代富文本编辑器(如 ProseMirror、Slate.js)不再直接操作 DOM，而是采用虚拟文档模型(如 ProseMirror Document / Slate Node Tree)，将编辑操作抽象为事务(Transaction)，通过命令模式(Command Pattern)来管理状态的变更、撤销和重做。

document.execCommand 是什么?为什么被废弃?

document.execCommand() 是浏览器提供的一组用于操作可编辑区域的命令 API，如 execCommand('bold')、execCommand('insertImage') 等。它曾是富文本编辑器的核心实现方式。

被废弃的原因：

各浏览器实现不一致，行为差异大，兼容性差

生成的 HTML 结构不可控，不同浏览器产生的标签不同

无法精细控制撤销/重做栈

已被 W3C 标记为过时，主流编辑器已转向自定义实现

富文本编辑器的数据模型有哪些?各有什么优劣?

表格

下载为表格

导出为图片

数据模型代表编辑器优点缺点

HTML 字符串wangEditor、UEditor直观、易于存储和渲染结构不可控、XSS 风险高

Delta/JSONQuill结构清晰、支持协同编辑需要额外的序列化/反序列化

虚拟 DOM 树ProseMirror、Slate.js精确控制、支持复杂操作学习曲线陡峭

Markdown ASTTiptap、Milkdown与 Markdown 互转方便对复杂富文本支持有限

 实战类面试题

如何实现富文本编辑器的图片上传功能?

核心流程分为以下几步：

监听编辑器的 paste、drop 事件或工具栏的图片按钮

获取 File 对象后，先将其转为 Base64 进行本地预览(使用 FileReader)

同时将文件通过 FormData + XMLHttpRequest/fetch 上传到服务器

上传成功后，将服务器返回的图片 URL 替换掉 Base64 的 src

关键考点：

上传前需进行文件类型和大小校验

需要处理上传失败的回滚(移除预览图)

大图片建议先压缩再上传

需携带认证 Token(如 JWT)

富文本编辑器如何处理粘贴内容?

粘贴是富文本编辑器最复杂的场景之一，需要处理以下问题：

从 Word 粘贴：Word 会携带大量冗余的样式标签和 mso- 前缀的私有属性，需要通过正则或 DOM 遍历进行清洗

从网页粘贴：可能携带外部样式、脚本标签，需要过滤

纯文本粘贴：需将换行符转换为

或
标签

实现方式：监听 paste 事件 → e.preventDefault() 阻止默认行为 → 从 clipboardData 获取内容 → 清洗 HTML → 通过编辑器 API 插入干净内容。

如何实现撤销/重做(Undo/Redo)功能?

传统方式：依赖浏览器的 execCommand('undo') / execCommand('redo')，但不可控

现代方式：采用命令模式 + 历史栈。每次编辑操作封装为一个 Command 对象，压入历史栈。撤销时弹出栈顶命令并执行其 undo() 方法，重做时重新执行 redo()。ProseMirror 等框架内置了完善的事务历史管理机制。

富文本编辑器如何实现协同编辑?

协同编辑的核心算法有两种：

OT(Operational Transformation，操作转换)：Google Docs 早期采用。核心思想是将用户的操作(如插入、删除)转换为可合并的原子操作，服务器负责协调多个客户端的操作顺序。

CRDT(Conflict-free Replicated Data Type，无冲突复制数据类型)：Yjs、Automerge 等库采用。每个操作自带唯一标识和因果关系，客户端可以独立应用操作，最终达到一致性，无需中心化服务器协调。

 安全类面试题

富文本编辑器如何防范 XSS 攻击?

富文本编辑器天然存在 XSS 风险，因为用户输入的内容会被渲染为 HTML。主要防护措施：

白名单过滤：只允许特定的 HTML 标签