BlockNote 调研：开发状态、扩展边界与富文本编辑器选型

BlockNote 官方网站

AI 参与说明（Agent：Codex）：本文根据 BlockNote、竞品官方文档、公开仓库、npm 与公共资助记录整理，覆盖产品概念、维护状态、扩展方式和选型边界。资料核查日期为 2026-10-08；发展前景与选型建议是依据公开证据作出的判断，不是维护承诺或性能排名。运行记录：模型 gpt-6.1-sol，reasoning effort ultra，执行入口 Codex Desktop，提供方 openai，CLI 版本 0.162.0-alpha.2（不代表桌面 App 版本）。

BlockNote 值得进入 React 文档、笔记与知识库产品的首轮选型，尤其适合希望快速获得 Notion 风格编辑体验的团队。 它的开发仍然活跃，已有实际下游采用和可核验的持续投入；主要代价是接受 BlockNote 的文档模型、跟进仍在变化的 API，以及为部分高级功能承担 XL 许可成本。

它并没有在所有场景胜过 Tiptap、Plate 或 Lexical。若编辑器本身是产品核心、需要很大范围改变文档结构和交互，Tiptap 或 Plate 可能更合适；若主要需求是审阅、Office 文档处理和企业支持，也应评估 CKEditor 5。本文先看维护证据，再解释工作原理和使用方式，最后给出同条件比较方法。

开发状态：活跃，但还不能按稳定平台对待

版本与维护节奏

截至整理日，GitHub 最新正式 Release 与 npm @blocknote/core 的 latest 都是 0.55.0，发布于 2026-09-22。按 GitHub Releases API 的 published_at 统计，2025-10-08 至 2026-10-08 之间有 34 个非草稿、非 prerelease 发布；这是项目 Release 数，不是把每个 npm 子包重复计算。v0.55.0、Releases API、npm metadata

这个节奏说明项目持续有人投入。比“有多少 Star”更有用的是观察最近版本修了什么、是否标明迁移路径，以及下游能否跟上升级。近期已有两次明显的接入变化：

• 0.52.0 拆分 Yjs 协作接入。 当前文档用 @blocknote/core/yjs 的 withCollaboration 包装编辑器选项。官网首页在本次核查时仍展示直接传 collaboration 的旧片段，因此复制首页演示代码时应再对照版本和参考文档。v0.52.0、Real-time Collaboration
• 0.53.0 的 shadcn 集成从 Radix 改为 Base UI。 对已有菜单、主题或底层组件定制的项目，这类依赖变更需要实际回归，不能只看 TypeScript 编译通过。v0.53.0

本文判断：BlockNote 已超出早期概念演示的阶段，但仍需要按快速演进的 0.x 产品管理升级。 不应因版本号小就否定生产采用，也不能因发布频繁就假设接口长期兼容。建议锁定同一版本的 @blocknote/* 包、保存 lockfile，并把自定义 Schema、粘贴、撤销和协作列入升级回归。

近期工作也包含实际能力改善：0.55.0 将移动 Formatting Toolbar 从 experimental 转为 supported；0.54.0 增加 Math / Diagram 相关能力；0.54.1 包含按 changed range 处理修改的性能优化与 Typst 导出路径。方向覆盖移动体验、技术内容、性能和输出质量，已经不只是补齐基础菜单。v0.55.0、v0.54.0、v0.54.1

真实采用与持续投入

法国 DINUM 的协作文档项目 Docs / La Suite Docs 在公开代码中采用 BlockNote。它是比官网客户 Logo 更具体的证据：能够查看应用依赖、接入代码和维护讨论；但单个下游的使用不能证明所有移动端、文档规模和权限模式均适用。Docs 依赖源码

OpenProject 也在公开依赖中使用 BlockNote，并维护独立的 op-blocknote-extensions。这既增加了真实采用证据，也提供了深入扩展的参考；它不能直接证明自己需要的扩展可无成本复用。OpenProject 依赖源码、OpenProject extensions

NLnet 的 NGI0 Entrust 项目页面记录了 BlockNote 的早期支持。更近的欧盟 ELFA 项目在 CORDIS 列出的周期是 2026-06-01 至 2029-05-31，参与方 OpenBlocks B.V. 的 Net EU contribution 为 €376,368.75。这笔金额是该公共项目中的资助记录，不能写成公司融资、收入或利润。NLnet BlockNote、CORDIS ELFA

官网自述为独立、bootstrapped 团队，公开商业路线包括 XL 订阅和企业定制支持。BlockNote、Pricing

据此，对其中期发展前景可以保持审慎乐观：底层技术有生态支撑，下游有真实需求，投入来源不只有个人兴趣。但公共资助与订阅方案不能证明现金流、团队规模或盈利，也不能构成 2029 年之前所有功能都有人维护的保证。采购支持时，应核对当前合同，而不是从资助期限推导 SLA。

维护集中度仍应关注：本次 GitHub Contributors API 的两页记录中，前三位贡献者约占累计 contributions 的 78%。口径含机器人记录，是 GitHub 归属的累计提交数，不代表工时、审阅或近期投入，也不能直接换算成团队人数。它提示长期选型需要关注核心维护者的持续参与，而不能只看贡献者总数。Contributors API、第二页、About

问题记录怎样解读

本次发现的具体风险信号包括：

开放 Issue 是调查入口，不等于所有使用者都会遇到的问题。本文没有在真实 iOS / Android、中文输入法或多人服务器上复现这些报告，也没有执行跨编辑器性能基准。

产品概念与能力范围

BlockNote is a block-based rich-text editor with a ready-made UI, built on Tiptap and ProseMirror. Introduction

开发者把它嵌入自己的 Web 应用，用户在应用里编辑内容。它主要面向 React，也允许高级使用者通过核心 API 自建 vanilla JavaScript 界面。它提供编辑器这一层；账号、文档列表、访问权限、媒体存储、搜索与发布工作流仍由应用维护。

能力来源：Built-in Blocks、UI Components、Custom Schemas、Comments、Format Interoperability。

需要注意两项成熟度边界：AI 文档仍标为 early preview；官网把 Suggestions & Versioning 标为 coming soon。能对 AI 输出接受 / 拒绝，不等于已经具备完整的人类 Track Changes 或可采购的文档版本历史。AI Integration、BlockNote homepage

它的 Table 是文档内容，不能据此推导出 Notion Database、关系视图、公式和完整项目管理能力。Office 导出也不能理解成任意 Word 文档无损导入和往返编辑；官方格式表需要逐项读。

工作原理：它替你承担了哪一层复杂性

flowchart TD
    U[BlockNote UI] -->|操作| B[BlockNote<br/>Block API / Schema]
    B -->|基于| T[Tiptap<br/>Extensions]
    T -->|基于| P[ProseMirror<br/>文档 / 选区 / 编辑事务]

图中表达编辑层的依赖关系，不是每次按键的精确调用栈。BlockNote 负责更贴近产品的 Block 操作与界面，底层仍使用结构化编辑机制。Introduction、Extensions

协作链路另行接入。Yjs 处理共享文档状态，Provider 负责把更新传到其他副本：Real-time Collaboration

flowchart TD
    B[BlockNote] -.->|可选协作集成| Y[Yjs]
    Y -->|通过 Provider 同步| S[协作服务 / 本地存储]

文档不是一串 HTML

一个 Block 有稳定的 id、type、props、content 和 children。例如标题可通过 props.level 表达级别，段落的 content 保存 Inline Content，嵌套列表通过 children 表达。Table 的内容结构又与普通段落不同。Document Structure

这样做的价值是，应用可以直接操作“这一段”“这个附件”“这个业务卡片”，而不用靠解析任意 HTML 判断其身份。需要同步维护的代价是 Schema：一篇包含 notice Block 的文档，消费它的编辑器和发布端都必须知道 notice 是什么。

BlockNote JSON is the recommended lossless storage format; standard HTML and Markdown conversions are lossy. Format Interoperability

因此，如果项目要求保留 Markdown / MDX 源码里的表达式、组件调用、自定义语法和排版，应先检查转换能否满足要求。把 Markdown 导入、编辑后再导出，不能自动视为原文件无损往返。适合的组织方式通常是保存原生 JSON，另生成 HTML / Markdown 阅读副本；需要源文件忠实编辑的产品，则应比较直接编辑源码的方案。

协作、离线与持久化各有职责

接入协作时，应用将 Yjs 文档中的 Fragment 交给 BlockNote，通过 Provider 传递增量更新。官方列出 Hocuspocus、Y-Sweet、Liveblocks、PartyKit、y-websocket 等选择；y-indexeddb 用于浏览器本地持久化。Real-time Collaboration

“支持 local-first”不表示仅安装编辑器就完成离线保存与多设备恢复。完整方案还需要决定：谁能连接某个文档、更新如何持久化、离线状态在哪里保留、备份怎样恢复，以及不同 Schema 版本如何兼容。协作模式下不能用两个客户端最后写入的完整 JSON 相互覆盖，来代替 Yjs 的合并过程。

Comments 的权限边界尤其具体：官方明确说明 ThreadStoreAuth 主要用于显示 / 隐藏界面操作，数据安全仍需服务端校验；直接使用 YjsThreadStore 时，没有合适的服务端限制，用户技术上可能修改他人评论。RESTYjsThreadStore 可以让写入经过后端授权，但这种写入路径不适合要求离线修改评论的 local-first 模式。Comments

可拓展性：业务内容很方便，彻底改变编辑范式成本更高

它提供的扩展面足够覆盖许多知识库和业务文档：

对应文档：Custom Blocks、Custom Inline Content、Custom Styles、Custom Schemas、UI Components、Extensions。

我的评价是：扩展业务内容很强，任意改变文档结构的自由度不如直接使用底层框架。 “能接入 Tiptap Extension”不能推出所有 Tiptap Node、Mark、NodeView 都能不经适配就组合；它们还要符合 BlockNote 的 Block 组织、选区与序列化约定。

开发一个新 Block 也不是把任意 React 组件塞进正文就结束：React 组件实现由代码提供，文档保存的是结构和属性。当前公开的 PropSchema 属性值类型限定为 string、number、boolean，复杂业务对象宜保存稳定 ID、由业务服务解析，或者明确设计版本化序列化；不能假设任意对象都可直接写进 props。Custom Blocks

本文建议的完整开发路径： 先定义类型和属性，再完成编辑渲染、插入入口、保存 / 恢复、只读发布和复制粘贴；最后用旧版文档检查迁移。toExternalHTML 与 parse 分别关系到外部 HTML 输出和导入识别，只有编辑器中“看起来正常”并不代表 Block 可长期使用。toExternalHTML 在独立 React root 中渲染，不能假设它继承应用的 React Context；省略它时会回退到 render，依赖业务 Provider 的组件应准备独立的外部渲染方式。Custom Blocks

使用方式：一个可复制的 React 示例

无需安装即可先体验 官方 Getting Started 与 Custom Blocks 示例。重点操作 / 菜单、拖动、嵌套、文字选区和自定义提示内容，观察是否符合目标产品的编辑习惯。

下面的 TypeScript / TSX 示例在已有 React 客户端工程中使用，包版本固定为 BlockNote 0.55.0，Mantine 8.3.11；@blocknote/mantine@0.55.0 的 peer dependency 接受 React 18 / 19 与此 Mantine 版本。Mantine setup、Package metadata

npm install --save-exact @blocknote/core@0.55.0 @blocknote/react@0.55.0 @blocknote/mantine@0.55.0
npm install --save-exact @mantine/core@8.3.11 @mantine/hooks@8.3.11 @mantine/utils@6.0.22

把下一段作为工程的 App.tsx，由现有 React 入口挂载并运行现有开发命令。它添加一个 notice Block，并用两个按钮演示 JSON 快照保存和恢复。快照只保存在组件内存里，刷新即清空；生产接入应把保存结果写到经过授权的持久化接口。

import { useState } from "react";
import { BlockNoteSchema } from "@blocknote/core";
import "@blocknote/core/fonts/inter.css";
import { createReactBlockSpec, useCreateBlockNote } from "@blocknote/react";
import { BlockNoteView } from "@blocknote/mantine";
import "@blocknote/mantine/style.css";

const createNotice = createReactBlockSpec(
  {
    type: "notice",
    propSchema: {
      tone: { default: "info", values: ["info", "warning"] },
    },
    content: "inline",
  },
  {
    render: ({ block, contentRef }) => (
      <aside
        data-tone={block.props.tone}
        style={{ border: "1px solid #888", padding: 12 }}
      >
        <strong contentEditable={false}>提示</strong>
        <div ref={contentRef} />
      </aside>
    ),
  },
);

const schema = BlockNoteSchema.create().extend({
  blockSpecs: { notice: createNotice() },
});

export default function App() {
  const [snapshot, setSnapshot] = useState("");
  const editor = useCreateBlockNote({
    schema,
    initialContent: [
      { type: "paragraph", content: "试试输入 /、拖动和文字格式。" },
      { type: "notice", props: { tone: "info" }, content: "这是自定义 Block。" },
    ],
  });

  return (
    <main>
      <BlockNoteView editor={editor} />
      <button onClick={() => setSnapshot(JSON.stringify(editor.document))}>
        保存快照
      </button>
      <button
        disabled={!snapshot}
        onClick={() => editor.replaceBlocks(editor.document, JSON.parse(snapshot))}
      >
        恢复快照
      </button>
      <pre style={{ whiteSpace: "pre-wrap" }}>{snapshot}</pre>
    </main>
  );
}

预期结果：出现普通段落和一个提示 Block；编辑后点击“保存快照”，JSON 中可见 type: "notice"、props.tone 与正文；继续修改后点击“恢复快照”，内容恢复到保存时的状态。新增类型出现在 Schema 中不会自动给它建立 Slash Menu 入口，实际产品还应补插入命令。Custom Blocks、Manipulating Content

本次实际验证：在 React 19.2.0、TypeScript 5.9.3 与 Vite 7.1.7 的客户端工程中，以上示例通过类型检查与生产构建；桌面浏览器中确认自定义 Block 可编辑、JSON 保留类型与属性、修改后能恢复快照，控制台未出现错误。本例没有接入多人协作后端，也未完成真实手机或中文输入法组合输入验收。

若只需要默认编辑器，去掉 createNotice 和自定义 Schema，使用 useCreateBlockNote() 即可。持续保存可使用 useEditorChange 读取 editor.document；远程保存还需设计节流、错误反馈和写入顺序，不能把每次键入发一个请求直接当成生产方案。Format Interoperability

界面有 Mantine、Ariakit、shadcn 等接入路径，也能自行组装。已有 UI 框架时应比较样式和依赖成本；选择 Mantine 的示例不代表必须把整个应用迁到 Mantine。内置本地化包含简体中文 zh，通过 dictionary 传入；中文界面与中文输入法的可靠性是两项不同的验收内容。Getting Started、Localization

编辑器界面需要在浏览器端运行。Next.js 的官方指南同时使用 Client Component 与关闭 SSR 的 Dynamic Import；这与服务端内容处理是两件事。服务端可通过 @blocknote/server-util 的 ServerBlockNoteEditor 转换文档和 Yjs 状态，但具体运行时及自定义 React 渲染需要单独验证，本文未验证 Edge / Workers 兼容性。Next.js setup、Server-side Processing

开源与商用成本：需要逐个包判断

The core editor is MPL-2.0; XL packages use GPL-3.0 or a commercial license. Pricing and licensing

MPL-2.0 是文件级 copyleft：分发时需要遵守相关源码与告知义务；分发修改后的 MPL 文件需提供对应源码，但不会因此要求整个闭源应用全部改成 MPL。浏览器收到的 JavaScript 也属于 Mozilla FAQ 所讨论的分发情形，不能简单将它当成“服务端 SaaS 所以没有义务”。Mozilla MPL FAQ，Q8–11、Q16–17

2026-10-08 核查的 Business 页面，默认年付价格为 US$2,340 / 年，折合 US$195 / 月；月付选项为 US$390 / 月。价格和折扣可能变化，应在采购时重新确认。Pricing

更值得关注的是 XL 商业条款：标准许可对应一个 Application、一个 Production Environment，并允许五个 Licensed Developers seats；已部署应用继续使用也要求有效商业许可，不能理解为购买一年、以后停在旧版本就可无限期使用。标准计划不提供 perpetual license，多应用或特殊部署应按条款与维护方确认。Commercial License，§2.4、§2.7、§3.2

支持承诺也要单独核查：Priority Support 的首次响应与 Standard Support 不同；当前 SLA 将修复支持限于最新版、不承诺旧版 backport。要求长期固定版本的团队，应把这一点纳入采购与升级预算。Technical Support SLA

未使用 @blocknote/xl-ai、自行开发模型调用和 Block 修改逻辑的方案，不应仅因“用了 AI”就被算作已使用 XL；但自行实现会承担更多编辑交互与测试成本，也须分别满足所用依赖的许可。

有没有更好的同类竞品

比较前应对齐层级：BlockNote 是包含默认 Block UX 的产品组件，Tiptap / Lexical 更接近编辑器框架，Plate 在框架之上提供插件和可复制的 UI。接入时间、自由度和维护责任不同，不能只按演示界面或 Star 数排名。

Tiptap：最值得与 BlockNote 同时评估的通用候选

Tiptap 的 Node、Mark、Commands、Extension 与 NodeView 更贴近底层模型。若需要复杂结构、特殊选区或一个横跨多类编辑场景的统一平台，这种自由度可能比 BlockNote 的现成 UI 更重要。NodeView

不要把 Tiptap 的实时协作笼统当成付费功能。 开源 Collaboration 与 Yjs 可以配合 MIT 的 Hocuspocus 自托管；Tiptap Platform 提供另一条托管和高级功能路线，收费边界应按所用产品检查。Hocuspocus、Hocuspocus LICENSE、Platform pricing

截至整理日，最新版本是 3.31.4（2026-09-30）。活跃维护和商业产品是持续投入的信号；团队仍需维护自己组合的 UI 和升级路径。BlockNote 与 Tiptap 有共同底层，不表示两者 JSON 可无损互换，迁移要映射节点、属性、嵌套与样式。v3.31.4

Plate：愿意维护组件源码时，定制空间很有吸引力

Plate 官方区分 platejs runtime、headless plugins 与可选 Plate UI。Plate UI 复制到应用成为本地代码，容易改造，也意味着升级 npm 包不会自动更新这些组件。Introduction

它有官方 YjsPlugin 和多种 Provider 接入。latest 为 53.3.16，GitHub 发布时间换算到北京时间为 2026-10-08，网页搜索缓存可能仍显示前一版。若已有 Slate 经验，或希望较大范围控制 React 界面，Plate 值得进入首轮；如果目标是尽快上线标准 Block UX，仍应实测是否比 BlockNote 节省总工时。Yjs、v53.3.16

Lexical：有生命力，但不是省去编辑器研发的捷径

Lexical 不建立在 ProseMirror 或 Slate 上，它使用自己的不可变 EditorState 和节点树，通过 Commands、Transforms、Listeners 等操作模型。Introduction

latest 是 0.52.0（2026-09-28）。官方 Release 明确描述向 1.0 演进并包含 Breaking Changes；0.51.0 已转为 ESM-only，新的 Lexical Extensions 也改变配置与组合方式。因此不能从 Meta 背景推导出“当前 API 稳定”或固定的长期支持期限。v0.52.0、v0.51.0、Lexical Extensions

对于有编辑器工程经验、愿意长期控制底层的团队，它很有价值；只是要做文档输入功能时，界面与升级成本可能抵消免费许可带来的优势。本次没有同条件 benchmark，不能宣布 Lexical 或任何候选性能胜出。

Editor.js 当前仍在维护（2.31.7，2026-09-17），但若多人实时协作是必需条件，官方协作 roadmap 使它不宜作为默认首选。CKEditor 5 当前为 48.5.2（2026-09-22）；它适合把企业文档流程置于优先级最高的团队，而非仅想接入轻量 Block 编辑的项目。Editor.js Release、CKEditor Release

怎样做一次有判据的选型验证

本文建议首轮只比较 BlockNote、Tiptap、Plate；已有底层编辑器经验再加入 Lexical。 先给所有候选相同文档、业务 Block 和保存接口，再比较完成同一体验的成本。不要把一个成品组件与另一个仅有段落输入的最小示例比较。

若要求完整 MDX 源码往返、复杂文档审阅、原生移动端组件，或者禁止所需功能的商业订阅，应先把这些列成不可妥协的条件。BlockNote 是 Web 编辑器，不能因为使用 React 就当成 React Native 原生编辑组件。

发展前景判断应在升级时复核：看 Release 是否继续提供迁移说明、关键问题是否获得修复、下游是否跟进、许可和支持政策是否变化。这比单纯追踪 Star 数更能帮助长期决策。

关联阅读

• Frontend Overview
• React 基础概念