Quill.js 与 Slate.js、Draft.js 选型对比：优缺点及适用场景分析

在前端开发中，富文本编辑器始终是一块具有高复杂度的技术领域。浏览器的 contenteditable API 在不同平台和输入法下的行为极其不一致，原生生成的 HTML 结构往往混乱且难以预测。为了抹平浏览器底层差异，各类现代富文本编辑器应运而生，但它们各自采取了截然不同的架构哲学。

结论先行：

• Quill.js：以 Delta 线性操作流 与 Parchment DOM 抽象 为核心，提供高度成熟的开箱即用体验（自带完整工具栏与双主题）。适合中后台管理系统、博客发布、问答社区以及需要跨不同前端框架快速上线的项目。
• Slate.js：以 嵌套 JSON 抽象语法树（AST） 与 React 原生组件渲染 为核心，完全不提供预置 UI。它是打造类似 Notion 的块级文档、多级嵌套卡片、自由排版画布的最佳基石，但要求团队具备自建全部交互组件的工程预算。
• Draft.js：作为 Facebook 早年推出的 React 富文本方案，基于 Immutable.js 和一维平铺的 Block 结构构建。目前 官方已正式停止维护并归档，Meta 内部主力演进为新一代 Lexical。新项目坚决不建议选型，存量项目应制定维稳或迁离计划。

一、底层数据模型与运行时架构剖析

富文本编辑器的扩展上限与维护稳定性，本质上由其底层数据模型决定。一旦数据模型无法自然表达业务所需的排版层级，后续任何上层封装都会变得极其别扭。

1. Quill.js：Delta 线性操作流 + Parchment 文档抽象

Quill 摒弃了直接操作 HTML 字符串的传统做法，自研了 Delta 数据格式。Delta 是一种基于 Operational Transformation（OT，操作转换）思想设计的线性 JSON 结构，它只由三种原子操作构成：insert（插入内容或嵌入对象）、retain（保留光标位移并赋予格式属性）以及 delete（删除指定长度）。

为了将这种平铺的字符级操作流映射到浏览器 DOM 树，Quill 引入了 Parchment 抽象层。Parchment 维护了一棵由 Blot 组成的轻量树，明确划分了 Scroll（根滚动容器）、Block（块级容器）、Inline（行内样式）以及 Embed（多媒体非文本节点）。当用户在编辑器中键入字符或调整格式时，MutationObserver 捕获变化并同步更新 Parchment 树与 Delta 状态。

2. Slate.js：纯粹的 JSON 树 (AST) 与声明式 React 绑定

与 Quill 的线性操作流不同，Slate.js 将文档状态视为一棵真正的 嵌套 JSON 节点树，其数据结构类似于微型 DOM 树或编译器 AST。树中的每个节点可以是 Element（拥有 children 数组的块级或行内容器）或 Text（包含字符串和布尔标记属性的叶子节点）。

Slate 的颠覆性在于它对视图层采取了“极致放权”策略：编辑器本身不负责绘制任何具体的工具栏、按钮或下拉菜单，所有的节点渲染全部委托给 React 的原生组件函数 renderElement 和 renderLeaf。这意味着开发者可以把富文本里的一个“折叠列表”或“代码沙盒”直接写成标准的 React 组件，享受 React 生态的全部状态管理与交互能力。

3. Draft.js：ContentState 与不可变数据结构的局限

Draft.js 诞生于 React 早期（2016年），其核心设计重度依赖于 Immutable.js。在 Draft.js 中，整个文档由 EditorState 包裹，核心内容存储在 ContentState 中。ContentState 的底层是一个平铺的 blockMap（一维有序块集合），而行内链接、Mentions、图片等富媒体则作为独立的 Entity 存放在分离的 entityMap 里。

这种一维平铺 Block 的设计，决定了 Draft.js 天生无法优雅支持多级嵌套结构（例如在表格单元格内嵌套待办清单，或在卡片内嵌套多列排版）。每次微小的输入都会触发 Immutable Record 的全量快照分配，在长文档场景下极易引发内存与垃圾回收压力。

二、核心指标多维度对比：优缺点深度剖析

在进行技术评估时，团队需要从开箱成本、结构自由度、多人协作与长期维护等多个维度进行综合权衡。

1. UI 成本：开箱即用 vs 自由定制

如果你的需求是在后台管理系统中提供一个支持加粗、标题、列表、图片上传和对齐方式的标准工具栏，Quill.js 具有碾压性的时间效率优势。只需几行代码引入 CSS 和 JS，一个精致且符合用户直觉的富文本交互界面即可就绪。

反观 Slate.js，它甚至不提供一个加粗按钮的 HTML 骨架。你必须自行编写 React 按钮、绑定 onMouseDown 阻止焦点丢失事件、调用 Editor.addMark、并自行处理响应式工具栏与浮层定位。如果团队没有 2 周以上的前端资源专门投入到 UI 开发中，直接选择 Slate 往往会导致工期大幅延误。

2. 数据结构：平铺线性 vs 树状多维

这是区分 Quill 与 Slate 适用边界的最根本分水岭。Quill 的 Delta 是线性的，用换行符 挂载块级属性。对于标准文章、邮件、博客这类“从上到下线性流式”的文本，Delta 表现得清晰而优雅。但在遇到 多列排版、可折叠卡片、多维表格（单元格内含复杂富文本） 这类场景时，Quill 的 Parchment 抽象层就显得相当吃力。

Slate 的 JSON 树天生支持 children 嵌套。在 Slate 中，一个表格就是包含了多个 table-row 的 table 节点，而每个 table-cell 又可以包含自己的段落与行内元素。数据树的结构与业务语义高度统一，在执行树遍历、深度查找和路径更新时具有绝对的工程优势。

三、代码实战对比：初始化与自定义扩展方式

通过具体的代码范式，我们可以更直观地看清三者在开发体验与架构设计上的落地点。

1. Quill.js：初始化与自定义 Blot 示例

Quill 的上手极其平滑。如果需要扩展一个自定义的行内标签（例如用于标记重要状态的 TagBlot），只需继承基础的 InlineBlot：

import Quill from 'quill';
import 'quill/dist/quill.snow.css';

// 1. 初始化标准编辑器（自带工具栏）
const quill = new Quill('#editor-container', {
  theme: 'snow',
  modules: {
    toolbar: [
      [{ header: [1, 2, false] }],
      ['bold', 'italic', 'underline'],
      ['image', 'code-block'],
      [{ list: 'ordered' }, { list: 'bullet' }]
    ]
  }
});

// 2. 自定义 Parchment Blot (状态标签)
const Inline = Quill.import('blots/inline');
class StatusTagBlot extends Inline {
  static blotName = 'statusTag';
  static tagName = 'span';
  static className = 'badge-tag';

  static create(value) {
    const node = super.create();
    node.setAttribute('data-status', value || 'info');
    return node;
  }

  static formats(node) {
    return node.getAttribute('data-status');
  }
}
Quill.register(StatusTagBlot);

// 3. 调用格式化 API
quill.formatText(0, 5, 'statusTag', 'warning');

2. Slate.js：初始化与自定义 React 组件渲染

在 Slate 中，开发者完全使用 React 的组件思想来主导节点渲染。以下代码演示了一个标准的 Slate 编辑器骨架与带自定义样式的引用块渲染：

import React, { useMemo, useState, useCallback } from 'react';
import { createEditor } from 'slate';
import { Slate, Editable, withReact } from 'slate-react';

const initialValue = [
  {
    type: 'paragraph',
    children: [{ text: '这是一个基于 Slate.js 的现代富文本实例。' }],
  },
  {
    type: 'quote-card',
    author: '架构评审组',
    children: [{ text: '只有当数据模型贴合业务实体时，交互定制才不会演变为灾难。' }],
  }
];

export const MySlateEditor = () => {
  const editor = useMemo(() => withReact(createEditor()), []);
  const [value, setValue] = useState(initialValue);

  // 自定义元素渲染器：像写普通 React 组件一样渲染富文本节点
  const renderElement = useCallback((props) => {
    switch (props.element.type) {
      case 'quote-card':
        return (
          <div {...props.attributes} style={{ borderLeft: '4px solid #77b9ae', padding: '12px 16px', background: '#1a3048', margin: '12px 0' }}>
            <div>{props.children}</div>
            <small style={{ color: '#83add0', display: 'block', marginTop: '6px' }}>—— 来源：{props.element.author}</small>
          </div>
        );
      default:
        return <p {...props.attributes}>{props.children}</p>;
    }
  }, []);

  return (
    <Slate editor={editor} initialValue={value} onChange={setValue}>
      {/* 工具栏由开发者自由拼装组件 */}
      <div className="custom-toolbar">...</div>
      <Editable renderElement={renderElement} placeholder="请输入内容..." />
    </Slate>
  );
};

3. Draft.js：blockRendererFn 模式及其维护痛点

Draft.js 依赖 blockRendererFn 来返回自定义组件。由于数据包裹在 Immutable.js 的 ContentBlock 中，组件内部读取元数据必须通过 block.getData().get('key') 这种老旧语法，且光标选区（SelectionState）在跨自定义组件移动时经常发生不可控的失焦跳变：

// Draft.js 遗留范式中的自定义块匹配
function myBlockRenderer(contentBlock) {
  const type = contentBlock.getType();
  if (type === 'atomic') {
    return {
      component: MediaBlockComponent, // 必须编写专门的包装层
      editable: false,
      props: {
        // 通过复杂方式提取 entity 与属性
      }
    };
  }
  return null;
}

四、项目实操选型决策树与排查步骤

面对具体的产品需求，技术团队应遵循系统化的排查路径，层层收敛选型范围，避免“用大炮打蚊子”或“小马拉大车”。

步骤 1：排查系统生命期（新启动 vs 存量改造）

如果是维护已经在线运行数年的存量 Draft.js 系统：若业务变动极少，建议锁死依赖版本保持维稳；若业务面临大规模重构或需要新增协同功能，应立即制定迁离方案，优先考虑迁移至 Meta 的 Lexical（概念更接近，上手顺手）或 Slate.js。

步骤 2：明确文本结构的复杂度上限

向产品经理核对核心交互形态：

• 用户是否只需要标准的行内排版（加粗、倾斜、下划线、颜色）、常规段落（标题、有序/无序列表）以及插入单张图片或音视频？如果是，系统属于 文档流排版，进入步骤 3A。
• 用户是否需要把每一个段落当作独立“块”（Block）进行拖拽排序、多列并排（Column Split）、嵌入实时交互卡片、甚至在单元格内嵌套表格？如果是，系统属于 块级多维排版，进入步骤 3B。

步骤 3A：权衡 UI 开发预算与交付工期（Quill 分流）

如果产品属于标准文档流，且研发周期只有 1~2 周，要求快速提供稳固可靠的编辑体验，Quill.js 是无可争议的最优解。即使是 Vue 或 Angular 团队，直接封装 quill 或使用成熟的 vue-quill 包装器，都能在几个小时内完成集成上线。

步骤 3B：技术栈匹配与定制自由度（Slate 分流）

如果产品是类似 Notion、飞书文档或企业级知识库的核心模块，必须拥有专属的 UI 风格、斜杠命令（Slash Commands）、浮动工具条与深度块交互：

• 若团队主技术栈为 React，且具备 2 周以上专属前端投入：坚决选择 Slate.js。它的 JSON 树和 React 原生渲染能带来极高的灵活性。
• 若团队主技术栈为 Vue 且需要块级编辑器：由于 Slate 与 React 强绑定，建议关注基于 ProseMirror 的方案（如 Tiptap）；而不要勉强用 React-in-Vue 包装 Slate。

步骤 4：确认实时协同编辑（OT / CRDT）的技术落地

若系统存在多人实时在线协作的需求：

• Quill.js 的 Delta 是 OT 算法的标准工业实现之一，与 ShareDB 或 y-quill (Yjs) 整合具有多年成熟生产实践，状态同步轻量且健壮。
• Slate.js 社区目前推荐搭配 slate-yjs，利用 Yjs 的 CRDT 算法解决多分支合并冲突，能够完美支撑复杂的树状结构协同。

五、落地场景归纳与存量迁移建议

结合工程实践，我们对三款编辑器的最终适用画像与避坑指南进行系统归纳：

1. Quill.js 最佳落地场景与雷区防范

最佳场景：

• 企业后台管理系统（CMS）的新闻、公告发布模块；
• 问答社区、博客平台、用户反馈与工单详情输入框；
• 中小型在线教育平台的作业提交与试题编辑；
• 需要兼顾 Vue、Angular、原生 JS 等多技术栈共存的前端基建。

2. Slate.js 最佳落地场景与架构建议

最佳场景：

• 对标 Notion、Craft 的现代个人与团队知识库产品；
• 具备高度自定义需求的合同签约、法律条款排版编辑器；
• 集成数据图表、代码演练场、表单卡片的富文档混合应用；
• 强依赖 React 生态并拥有专职交互设计团队的 SaaS 产品。

3. Draft.js 存量项目的维稳与平滑迁移路线

如果你的系统依然运行着庞大的 Draft.js 遗留代码，可以按以下策略分阶段治理：

1. 第一阶段：只修不改（Freeze & Stabilize）。锁定 React 版本至 17 或 18 兼容模式，严禁向 Draft.js 中增加深度嵌套的新功能特性。
2. 第二阶段：数据层适配转换（AST Converter）。Draft.js 的数据是以 rawContentState JSON 格式持久化的。编写转换脚本，将单层 blocks + entityMap 转换为标准的通用 JSON 树或 HTML。
3. 第三阶段：平行替换（Canary Migration）。如果是纯 React 技术栈且习惯 Meta 生态，推荐渐进迁移至 Lexical；若产品需要大幅升级为块级交互架构，则推荐在新建或重构页面直接切入 Slate.js。