TinyMCE与CKEditor：JS富文本编辑器的功能特性对比

一、底层架构与数据流动模式对比

富文本编辑器的所有能力边界，最终都由其底层数据流动机制决定。浏览器提供的 contenteditable 属性原生存在行为碎片化、跨浏览器节点插入不一致等问题。TinyMCE 与 CKEditor 5 对此给出了完全不同的架构解答。

1. TinyMCE：基于原生 DOM 树与 iframe 物理沙箱

TinyMCE 延续了深耕 Web 标准二十余年的经典架构路线。它直接以浏览器的原生 DOM 树和 HTML 字符串作为核心数据实体。用户在编辑区内的敲击、换行或退格，直接被映射到浏览器底层的 DOM 节点操作。

TinyMCE 最显著的设计特征是其默认的 <iframe> 容器隔离机制（虽然也支持 inline 模式）。编辑器将整个编辑区嵌入在独立的 iframe 文档中，这使得宿主系统的全局样式（如 CSS Reset、Bootstrap 或 Tailwind 的全局选择器）完全无法渗透污染编辑内容。同时，编辑区域内的排版样式通过 content_style 或 content_css 显式注入，实现了可控的排版渲染环境。

这种架构的最大收益是“直观与无损输出”：在编辑器中看到的即是标准的 HTML，通过 editor.getContent() 获取的也是原汁原味的 HTML 字符串。然而其局限在于结构控制较弱，一旦有非预期的 HTML 标签或内联样式被贴入，通常只能依赖正则表达式或白名单标签过滤器（如 valid_elements）进行事后清洗。

2. CKEditor 5：基于虚拟数据模型的 MVC 渲染管道

与 CKEditor 4 的传统架构彻底决裂，CKEditor 5 完成了一次彻底的现代化重构。在 CKEditor 5 内部，DOM 树不再是状态的持有者，仅仅是最终渲染呈现给用户的一个“视图”（View）。

CKEditor 5 引入了自研的 Model（虚拟数据模型）。所有文本、块级容器、内嵌属性首先以树状模型存储在内存中。当外部 HTML 导入或剪贴板内容贴入时，必须经过 Upcast 转换器（Upcast Dispatcher）；模型发生变更后，经过 Downcast 转换器（Downcast Dispatcher）将变化同步到 View DOM。

更为关键的是，Model 受到全局 Schema 的绝对约束。任何没有在 Schema 中显式注册允许的标签、嵌套关系或属性，在 Upcast 阶段就会被直接剥离抛弃。这意味着非法的 HTML 根本无法进入模型层，从而在根源上保证了富文本数据的整洁度与语义一致性。

二、插件开发与二次开发扩展体验

在实际企业级业务落地中，原生富文本往往无法满足需求，团队几乎不可避免地需要开发自定义业务卡片、商品嵌入模块或特色标记组件。两者的二次开发机制体现出了完全不同的抽象层级。

1. TinyMCE 自定义插件实现方式

在 TinyMCE 中开发一个自定义提示卡片（Callout）插件极其直接。开发者只需调用 PluginManager.add()，通过 editor.ui.registry.addButton() 注册工具栏按钮，并在点击事件中通过 editor.insertContent() 插入 HTML 字符串即可。整个过程完全符合标准前端的 DOM 认知。

// TinyMCE 自定义提示框插件示例
tinymce.PluginManager.add('customCallout', function(editor) {
  // 注册工具栏按钮
  editor.ui.registry.addButton('customCallout', {
    text: '提示卡片',
    tooltip: '插入业务提示框',
    onAction: function() {
      // 获取当前选区内容
      const selected = editor.selection.getContent() || '请输入重要提示...';
      // 直接拼接并插入具有特定样式的 HTML 节点
      const html = `<div class="callout-box" style="padding:12px;background:#F0F4F8;border-left:4px solid #52677D;border-radius:4px;">${selected}</div><p></p>`;
      editor.insertContent(html);
    }
  });
});

// 初始化并加载插件
tinymce.init({
  selector: '#tinymce-editor',
  plugins: 'customCallout table code lists',
  toolbar: 'undo redo | bold italic | customCallout | table'
});

2. CKEditor 5 自定义插件实现方式

在 CKEditor 5 中开发相同功能的提示卡片插件，则需要遵循严格的 MVC 设计模式。开发者需要创建继承自 Plugin 的类，并在 init() 阶段分别处理 Schema 声明、命令绑定（Command）、Upcast/Downcast 转换器以及 UI 工厂绑定。

// CKEditor 5 自定义提示框插件示例
import { Plugin } from '@ckeditor/ckeditor5-core';
import { ButtonView } from '@ckeditor/ckeditor5-ui';

export class CalloutPlugin extends Plugin {
  init() {
    const editor = this.editor;
    const { schema, conversion } = editor;

    // 1. 在 Model Schema 中声明 calloutBox 节点属性
    schema.register('calloutBox', {
      inheritAllFrom: '$block',
      allowIn: '$root'
    });

    // 2. 配置 Upcast 转换器：将 HTML 转换进虚拟模型
    conversion.for('upcast').elementToElement({
      model: 'calloutBox',
      view: { name: 'div', classes: 'callout-box' }
    });

    // 3. 配置 Downcast 转换器：将虚拟模型渲染为视图 DOM
    conversion.for('downcast').elementToElement({
      model: 'calloutBox',
      view: (modelElement, { writer }) => {
        return writer.createContainerElement('div', { class: 'callout-box' });
      }
    });

    // 4. 在 UI 组件工厂中注册按钮与点击逻辑
    editor.ui.componentFactory.add('customCallout', locale => {
      const view = new ButtonView(locale);
      view.set({ label: '提示卡片', withText: true });
      view.on('execute', () => {
        editor.model.change(writer => {
          const box = writer.createElement('calloutBox');
          editor.model.insertContent(box);
        });
      });
      return view;
    });
  }
}

三、核心功能特性与工程指标多维剖析

除了架构与扩展方式，富文本编辑器在日常开发运维中的功能成熟度直接决定了业务交付效率。下表与图表从多个关键技术维度对两者进行了综合比对。

1. 复杂排版与表格能力

在企业日常公文、合同录入与报表编辑中，表格是使用频度最高的排版工具。

• TinyMCE：在表格细粒度控制上表现极其强悍。支持直观的可视化拖拽调整列宽与行高、不规则单元格合并/拆分、单元格独立背景色设定、边框单独样式控制等。其排版模型高度还原经典 Microsoft Word 的使用体验，非技术编辑人员无需培训即可直接上手。
• CKEditor 5：表格功能建立在 Model 结构之上，其底层要求表格必须是行列对称规范的矩阵结构。尽管支持单元格合并与基本样式，但在一些非标的复杂多级表头嵌套、或者特殊 CSS 定位排版上，CKEditor 5 会为了保证模型树的一致性而限制自由排版。

2. 剪贴板清洗与 Office 格式解析

从 Microsoft Word、WPS 或 Excel 复制图文混合内容并粘贴到编辑器，是富文本崩溃和垃圾样式污染的高发区。

• TinyMCE：其开源版本自带基础的 paste 插件，能过滤常见的垃圾标签；而其商业方案中的 PowerPaste 插件 被公认为业内粘贴解析的最强标杆，能够将 Word 极其杂乱的 MSO 样式标签、内嵌矢量图形、公式与嵌套表格完美转换清洗为整洁的 HTML。不过该插件属于纯闭源商业模块，需按月/年付费订阅。
• CKEditor 5：开源版本即内置了基于 Upcast 转换管道的剪贴板清洗机制。由于有严格的 Schema 白名单机制，任何外部粘贴进来的非法 style="mso-..." 或冗余 <o:p> 标签在转换阶段便被自动剥离，生成的输出天然具备极高的纯净度，但对于复杂嵌套表格的版式还原度略逊于 PowerPaste。

3. 实时多人协同就绪度（Real-time Collaboration）

随着在线协作文档（如飞书文档、腾讯文档、Google Docs）的普及，多人同时编辑同一篇文章的需求激增。

• TinyMCE：由于底层是直接修改 DOM 树，直接自研操作转换（OT）或无冲突复制数据类型（CRDT）极其困难。TinyMCE 官方提供基于 Tiny Cloud 的协作套件，但自建开源协同方案门槛极高，往往容易出现光标丢失或节点竞态覆盖。
• CKEditor 5：从设计第一天起就是为了协同而生。其虚拟 Model 上的所有修改都被封装为细粒度的原子操作（Operations），这与 OT/CRDT 算法在数学结构上完全对齐。官方提供了开箱即用的 Cloud Services 协同套件；在自研场景下，社区也能够较为顺畅地将 CKEditor 5 与成熟的开源协同库 Yjs 对接，实现低延迟的多人协同与历史版本回溯。

四、开源协议、商业化考量与合规风险

富文本编辑器的选型不仅是技术选型，更是法务与商务决策。开源许可证的演变直接关系到商业闭源软件的合规安全。

五、业务选型决策路径与落地清单

综合以上各维度的技术细节，工程团队应根据自身业务形态的根本诉求进行选型分流。