GrapesJS 与 Gutenberg：你应该选择哪种可视化编辑器？

两者都是真正的视觉编辑，且都被积极维护。它们是为不同工作设计的，所以有用的问题是你现在做的是哪种工作。

选择更多取决于哪个编辑器功能更多，而是你的产品需要如何运行。

本页后面几乎所有的差异都源于一个原因：每个项目的目标是什么。

这两者都不是对彼此的批评。一个拥有你出版流程的CMS正是你想要的，因为网站就是产品。一个不拥有任何东西的框架正是你想要的，因为编辑必须生活在你已有的东西里。

Gutenberg 是 WordPress 原生的编辑体验。GrapesJS 是一个构建你自己视觉编辑体验的框架。

从上到下阅读每一列。两者的层概念是一样的——某个东西托管编辑器，编辑器生成内容，内容被存储并渲染——但这两个项目从相反的两端进入这条链。

注意每个链条的起点。Gutenberg 的第一个框是 WordPress：编辑器存在是因为它周围有发布系统。GrapesJS 链条从你的应用程序开始，框架占据恰好一个链接。这个差异解释了下表中的存储行、插件行和白标行。

能力，而非分数。当能力在双方都存在时，行会说明;如果一方通过工作而非环境达到，则行会说出能力。

每一行都是从两个项目自己的文档中朗读的 2026-09-03. 没有行标记了两个项目实际具备的功能：Gutenberg 注册自定义区块，支持区块模式和模板，暴露过滤器和 slot fills 作为接口，并将编辑器发布到 npm——这些行读取的是“可扩展”和“可能”，而非“否”。资料来源: Block Editor Handbook · Block 注册 · Block 编辑器包 · 网站编辑器 · GrapesJS 文档 · Components · 存储

看看独立的可视化编辑器与原生 WordPress 编辑体验有何不同。这是本页中运行的真实 GrapesJS 实例——把区块拖进来，选中任意元素重新设置样式，切换画布宽度，并打开资源管理器。

你看到的是框架的默认界面。里面的每个面板、按钮和控件都是可替换的——这就是表格中“自定义编辑器界面”行描述的区别。

Gutenberg 可以用来通过 WordPress 区块构建页面和布局，但它的主要作用是 WordPress 区块编辑器和内容编辑系统。

这个问题通常隐藏着四个不同的东西。将它们分开后，答案就变得简单明了。

1. 1

   WordPress 内容编辑器

   用于写入帖子或页面的界面。这是Gutenberg的核心工作：基于区块的写作界面取代了传统的单文本字段。

2. 2

   WordPress 网站编辑

   使用区块主题时，同一个区块界面会编辑模板、页眉、页脚和模板部分。这就是为什么“页面构建”更能公平地描述人们在其中所做的事情。

3. 3

   从积木构建页面

   从区块、图案和可复用模板组装布局。Gutenberg 可以做到这一点，之前的商业 WordPress 页面构建器也是如此。

4. 4

   独立视觉编辑器框架

   一个你嵌入在自己拥有的应用程序中，没有附加CMS的库。这就是GrapesJS，也是这份列表中Gutenberg本来就没设计成的。

所以：是的，前三个，这也是大多数人指的。如果你在寻找Gutenberg页面构建器的替代品，是因为你想要第四个——一个可以放进自己产品里的编辑器——那是另一类工具，这也是这个页面的主题。

这些都是真实且常见的情况，每一次增加第二个编辑器都会让项目变得更糟而非更好。

这些编辑器都是你发布的功能，而不是团队登录的屏幕。

比较意味着选择，而当没有选择时，就是这种情况。你不一定非得替换WordPress。

WordPress 可以继续处理内容、用户、权限和后端工作流，而 GrapesJS 则提供可视化编辑层。在这种安排中，两者是对等的：一方拥有数据及其相关规则，另一方拥有作者所看到的内容。

三条路线，都不是自动的

• 通过WordPress REST API

  你的应用程序托管编辑器，并通过WordPress自身的REST端点读写内容。WordPress保持不动;认证和能力检查才是需要关注的部分。

• 作为 WordPress 插件

  编辑器会被列在管理员界面，通过你自己注册的路由保存，使用nonce和能力检查。内容会留在WordPress，你的用户也是如此。

• 通过你自己的应用层

  服务位于编辑器和WordPress之间，拥有双向的映射。工作量最大，也是唯一能存活的路径，拥有多个内容源。

同样的拆分，但更进一步：WordPress停止渲染网站，成为纯粹的内容后端，而编辑器和前端都是你的。

• WordPress

  保持内容后端

  • 内容存储与修订
  • 用户、角色与能力
  • 媒体库
  • 编辑工作流程与排班

• GrapesJS

  变成了编辑体验

  • 视觉画布
  • 你的区块和组件类型
  • 样式控制与约束
  • 无论你选择哪种界面，作者都选择

• 你的前端

  渲染结果

  • 你的框架和你的路由
  • 你的绩效预算
  • 你的缓存与部署
  • 是你的加价，不是主题的

这种安排能为你带来什么

• 为你的作者而非WordPress量身定制的定制编辑体验
• 编辑器与前端之间的清晰分离
• WordPress 仍然是内容后端，其工作流程保持完整
• 一种基于自身优点选择的前端架构
• 这是一条更简单的路径，可以把编辑器用别人的品牌发行

值得明确的是成本：一旦WordPress停止渲染网站，依赖主题的插件就不再影响网站，预览需要在前端重新构建，任何用来在PHP渲染的区块现在都得在别处渲染。

这就是大多数迁移计划背后的问题：我们已有的区块能跟随我们一起走吗？比较这两种形状比任何段落都更快给出答案。

// A Gutenberg block, as authored in a
// WordPress plugin.
registerBlockType( 'acme/hero', {
  attributes: {
    title:       { type: 'string' },
    description: { type: 'string' },
  },
  supports: { align: [ 'wide', 'full' ] },
  edit:  ( props ) => <HeroEdit { ...props } />,
  save:  ( props ) => <HeroSave { ...props } />,
} );

// The same idea in GrapesJS: a component
// type, plus a block that inserts it.
editor.Components.addType('hero', {
  model: {
    defaults: {
      traits: ['title', 'description'],
      attributes: { class: 'hero' },
      components: [
        { type: 'text', tagName: 'h1' },
        { type: 'text', tagName: 'p' },
      ],
    },
  },
});

editor.BlockManager.add('hero', {
  label: 'Hero',
  category: 'Sections',
  content: { type: 'hero' },
});

是的，但迁移通常是架构转换，而不是简单的导出或导入操作。

没有转换器，也不太可能出现——原因请参见上面两个代码示例。实际上存在的是相当可预测的工作序列。

三个形状，按工作顺序递增排列。我们故意不给出持续时间：相同的区块数量，可能是两周，也可能是一个季度，取决于这些区块到底做什么。

1. 1简单

   主要由标准区块构成

   内容主要由核心区块构建，布局也很传统。

   • 主要由标准区块构成
   • 有限的自定义功能
   • 少量模板
   • 主题样式表里的样式
2. 2中等

   自定义区块与自定义样式

   拥有属于自己的区块库，以及已经定制过一次的编辑体验。

   • 自定义区块
   • 自定义样式
   • 模式
   • 定制编辑器界面
   • 与外部服务的集成
3. 3复杂

   动态渲染与深度集成

   这些区块实际上是PHP，而WordPress的安装是业务的运行材料。

   • 动态区块
   • 在PHP中渲染
   • WooCommerce
   • 定制WordPress插件
   • 深度集成的WordPress工作流程
   • 大型模板库

如果你的项目在第三栏，值得先问的问题不是“我们如何迁移？”而是“这部分到底需要换个编辑器？”——答案往往是一个屏幕，而不是整个网站。

你不必自己构建每一个编辑器功能。用插件扩展 GrapesJS 以实现通用功能和集成——就像 WordPress 项目选择插件而不是写插件一样。

Blocks

作者拖拽到画布上的现成区块，从基础版面到完整的页眉和页脚。

浏览该类别

核心区块

Plugin Basic Blocks

大多数编辑器都是从这套基础区块开始的。

免费查看插件

布局区块

Users Blocks

为需要布局多样性的团队提供更广泛的库。

¥424.80查看插件

页眉区块

Super Header for GrapesJS

作者可以配置页眉区块，无需操作标记。

¥280.80查看插件

页脚区块

Super Footer for GrapesJS

页脚部分采用相同的配置模型。

¥280.80查看插件

富文本编辑

把内置的内联文本编辑器换成完整的编辑工具栏。熟悉的名字，运行在画布内。

浏览该类别

内联编辑

GrapesJS Inline Text Editor — Compatible with CKEditor 5

画布内有完整的编辑工具栏。

¥496.80查看插件

内联编辑

TinyMCE 8 Inline Text Editor

一个熟悉的工具栏，供从其他系统转来的作家使用。

¥496.80查看插件

内联编辑

Froala Inline Text Editor

如果用户已经知道，还有第三种选择。

¥496.80查看插件

工具栏附加功能

Grapesjs RTE Extensions

内置的在线工具栏上有额外控制。

免费查看插件

存储与集成

编辑器保存的地方。这是WordPress REST路由插入的层——同一接口，不同的端点。

浏览该类别

后端存储

Directus Storage

直接存档到无头后端。

免费查看插件

后端存储

Grapesjs Firebase Storage

保存到一个没有自己服务器的托管数据库。

免费查看插件

本地存储

IndexedDB Storage

在发送任何东西之前，先把草稿保存在浏览器里。

免费查看插件

多页

Pages Manager

把一幅画布变成多页的项目。

¥180.00查看插件

CSS 框架与样式

Tailwind 和 Bootstrap 块集，这样编辑器生成的标记就和你已经发布的设计系统一致。

浏览该类别

Tailwind

Grapesjs Tailwind

针对你已经发布的实用职业来写作者。

免费查看插件

Tailwind 区块

Plugin Blocky for Tailwind CSS

基于这些类构建了一个区块库。

¥424.80查看插件

Bootstrap 5

GrapesJS Bootstrap v5 Blocks

会产生当前的Bootstrap加价。

免费查看插件

Bootstrap 4

Bootstrap 4 Blocks for GrapesJS

同样，对于仍在前一大版本的项目也是如此。

免费查看插件

七个具体产品，每个都是负责不同职责的编辑。

核心与框架无关：它渲染成 DOM 元素，因此集成主要取决于哪个生命周期钩子调用初始化器。

有一点需要明确说明：GrapesJS 不是原生的 React、Vue 或 Angular 组件编辑器。它在自己的画布中编辑 HTML 和 CSS，框架包装器是你挂载和控制它的方式，而不是画布的渲染方式。如果你需要框架自己的组件在画布内实时渲染，那是不同的需求和工具。

找到与你正在构建的产品相匹配的行。其中五个指向Gutenberg，这不是礼貌——而这正是这些项目应该从这里开始的。

大多数团队会做出这种比较，介于“Gutenberg还行”和“我们正在打造产品”之间。这里有三个立场，而不是两个。

• 选项一

  保留Gutenberg

  选择这个原生的WordPress编辑已经足够了，你感受到的摩擦其实是主题或插件的问题，而不是编辑器本身的问题。

  这是最便宜的选择，远远超过类似页面的正确选择。本网站没有任何理由将一个正常运行的WordPress网站从其独立编辑器中移除。

  工作内容

  • 无迁移
  • 没有第二系统需要维护
  • 你团队已经知道的一切
  Block Editor Handbook
• 选项二

  扩展Gutenberg

  选择这个你需要额外的区块、额外的控制，或者更紧凑的编辑界面——但WordPress的编辑模型本身非常适合你。

  Gutenberg 确实是可扩展的。自定义区块、区块模式、block supports、过滤器和 slot fills 覆盖了人们说编辑器不按他们想要的功能所说的很大一部分。

  工作内容

  • 注册你自己的区块
  • 限制作者可以更改的内容
  • 通过滤镜调整编辑界面
  Block 过滤器参考
• 选项3

  添加GrapesJS

  选择这个你需要一个独立或更可定制的视觉编辑体验——通常是因为编辑器是你销售产品的一部分。

  添加而非替换：WordPress 可以保持原位，拥有内容和用户，而第二个编辑面则满足它本不该设计的用途。

  工作内容

  • 一个你完全控制的可视化编辑器
  • WordPress 作为内容后端保留
  • 你拥有的集成层
  WordPress 集成指南