Plate 项目 Slate v2 技术选型扫描ProseMirror 与 Lexical 五大接缝的借 / 拒 / 延决策指南【免费下载链接】plateRich-text editor with AI and shadcn/ui项目地址: https://gitcode.com/GitHub_Trending/pl/plate本文是 Plate 项目 Slate v2 研发路线中的一份技术选型研究报告核心主题是在 Slate v2 重构过程中如何围绕transaction/update 模型、history/bookmark 语义、clipboard 边界、extension/plugin 组合、React 运行时订阅模型这五个接缝seam对 ProseMirror 与 Lexical 两个成熟编辑器进行定向源码扫描并据此为slate、slate-dom、slate-react、slate-history、slate-browser五个包给出「借borrow/ 拒reject/ 延later」三级决策。读完本文你将掌握这套跨编辑器架构比较的方法论、扫描结论的完整决策矩阵以及每个决策在当前仓库源码中的印证位置。一、背景为什么需要对 ProseMirror 与 Lexical 做定向扫描Slate v2 是 Plate 项目对 Slate 编辑器的现代重构方向其核心哲学是「继承 Slate 的数据模型与公共操作约束但不盲从任何第三方」。在重构的关键节点上团队选择对业界两个最有代表性的编辑器——ProseMirror 与 Lexical——做一次新鲜的、聚焦的代码扫描fresh focused code scan目的不是模仿或移植而是用它们检验自己的架构决策是否站得住脚。这场扫描的原始计划记录在 2026-04-06-slate-v2-prosemirror-lexical-roadmap-scan.md其结论沉淀为 package-end-state-roadmap.md 的附录该文件现已被归档为历史参考文档。当前路线图的权威真相以 master-roadmap.md 为准。1.1 五个被扫描的接缝seam所谓「接缝」是指编辑器架构中子系统之间的职责分界点也是最容易产生架构漂移的地方。本次扫描锁定五个接缝接缝要回答的核心问题transaction/update 模型状态变更如何被表达、暂存、提交变更是否可追踪、可回放history/bookmark 语义撤销/重做如何划分批次选区在历史操作后如何恢复clipboard 边界序列化、解析、内部元数据应该住在哪一层extension/plugin 组合扩展机制是核心内置还是插件注入时机是否成熟React/runtime 订阅模型React 运行时如何订阅编辑器状态会不会引发全局重渲染1.2 为什么挑这两个项目对比ProseMirror以严格的 transaction 纪律、插件系统、DOM 权威DOM authority over state著称适合检验 Slate v2 的「事务化核心 显式 DOM 桥接」路线。Lexical以不可变 editor state、自定义 reconciler、React 包拆分著称适合检验 Slate v2 的「不可变提交快照 selector 优先订阅」路线。两者恰好覆盖了 Slate v2 最关心的两个压力方向因此扫描结论被明确写入路线图ProseMirror 是slate-dom与slate-history细化方向的更强参考源Lexical 是slate事务/更新压力以及后续slate-react/history 细化想法的更强参考源见 package-end-state-roadmap.md 的「Appendix Bottom Line」。二、扫描方法五个阶段与两份文件清单计划文档把整个扫描组织为五个阶段前两个阶段是「读源码、画地图」后三个阶段是「收敛结论、落进文档」在prosemirror仓库中为五个接缝逐一映射精确源码文件在lexical仓库中为五个接缝逐一映射精确源码文件为slate、slate-dom、slate-react、slate-history、slate-browser五个包提炼具体可吸收的要点以「borrow now / reject / later」三级分类修订路线图附录校验格式并总结变更。从仓库侧印证这一方法的是最终产物确实是一份「五包 × 三级决策」的附录且明确声明「用这份附录去给包级决策施压pressure package decisions但不要让它在优先级上凌驾于队列之上」。2.1 ProseMirror 侧被扫描的文件扫描计划只圈定与五个接缝直接相关的 5 个文件不做全仓库漫游文件对应接缝state/src/state.tstransaction/update 模型state/src/transaction.tstransaction/update 模型state/src/plugin.tsextension/plugin 组合history/src/history.tshistory/bookmark 语义view/src/clipboard.tsclipboard 边界2.2 Lexical 侧被扫描的文件Lexical 侧的文件清单更长因为它把事务、编辑器、reconciler、历史、剪贴板、选区、扩展、React 订阅拆分到了不同包文件对应接缝packages/lexical/src/LexicalEditorState.tstransaction/update 模型packages/lexical/src/LexicalUpdates.tstransaction/update 模型packages/lexical/src/LexicalEditor.tstransaction/update 模型packages/lexical/src/LexicalReconciler.tstransaction/update 模型packages/lexical-history/src/index.tshistory/bookmark 语义packages/lexical-clipboard/src/clipboard.tsclipboard 边界packages/lexical-selection/src/index.tsclipboard 边界选区子系统packages/lexical-extension/src/LexicalBuilder.tsextension/plugin 组合packages/lexical-react/src/LexicalComposer.tsxReact/runtime 订阅模型packages/lexical-react/src/useLexicalSubscription.tsxReact/runtime 订阅模型packages/lexical-react/src/LexicalOnChangePlugin.tsReact/runtime 订阅模型三、五包决策矩阵借什么、拒什么、延什么这是全文的核心。五个包各自拥有独立的「Borrow Now / Reject / Later」三段式结论任何新提交的代码切片都必须能落进其中一格否则就属于「漂移」。3.1slate事务优先的文档核心End-state 定位拥有文档语义、操作模型、事务执行、不可变提交快照、运行时身份、显式替换/重置入口不拥有DOM 翻译、浏览器事件语义、React 运行时策略。Borrow Now现在就借ProseMirror 的事务形态纪律参考state/src/state.ts与state/src/transaction.ts保持「一个持久 editor 状态 一个显式 transaction 对象 一条 apply 路径」。这对应到当前仓库就是 master-roadmap.md Tranche 3 确立的公开生命周期层级editor.read读、editor.update写边界、原始 editor 方法灵活变更 API、事务拥有的目标新鲜度、EditorCommit作为本地运行时真相。Lexical 的不可变 editor-state 压力参考LexicalEditorState.ts与LexicalUpdates.ts提交态保持不可变把「更新」当作独立的分阶段单元。这与当前仓库packages/slate的提交快照契约committed snapshot contract方向一致。Reject现在拒绝ProseMirror 的核心内置插件定义状态参考state/src/plugin.ts「好架构错时机」。v2 核心不应在替换候选稳定之前重新打开插件模型。这一点在 package-end-state-roadmap.md 的slate一节被明确列为「Intentionally Latermiddleware/plugin phase pipeline」。Lexical 的定制 reconciler 模型参考LexicalReconciler.ts离 Slate 的数据模型与公开操作约束太远。Later以后再说Lexical 的 update-tag 词汇表参考lexical-history/src/index.ts与LexicalUpdates.ts作为事务元数据transaction metadata的细化方向。ProseMirror 的插件事务钩子参考plugin.ts仅当engine.md中的 middleware/end-state 方向后续被复活时才考虑。3.2slate-dom浏览器边界拥有者End-state 定位拥有 DOM point/path 转换、DOM selection 桥、clipboard 浏览器边界、嵌套 editor 与 shadow/iframe 边界规则、真正属于浏览器层的 composition/input 传输不拥有React hooks、运行时订阅、editor 语义。Borrow NowProseMirror 的显式 clipboard 边界参考view/src/clipboard.ts序列化、解析、内部元数据都住在 DOM 边界而不是散布在 React 层。当前仓库的印证是packages/slate-dom的ClipboardBridge与DOMBridge它们正是这条「显式浏览器边界」主张的实现见 package-end-state-roadmap.md 中slate-dom的「Done Now」与 Proof Gates。Lexical 的 clipboard selection 拆分拥有权参考lexical-clipboard/src/clipboard.ts与lexical-selection/src/index.ts选区与剪贴板是严肃的浏览器子系统不是事后补丁。RejectProseMirror 式的「DOM 权威于状态」Slate v2 已经选择了「提交态核心快照 显式 DOM 桥接」不采纳 view 栈中那种 DOM 对状态的全面控制。Lexical 的全浏览器拥有栈形态有用但与 Lexical 的 node/reconciler 模型耦合太深不能直接导入。LaterProseMirror 式更丰富的 clipboard 上下文元数据参考data-pm-slice处理仅当当前 fragment 元数据被证明太弱时。Lexical 选区子系统思路仅当当前 DOM selection 压力暴露出真实缺口时。3.3slate-reactReact 19.2 运行时End-state 定位拥有快照驱动运行时接线、selector 订阅、稳定 editor 实例语义、React 中的显式替换/重置消费、DOM 桥周围的 React 生命周期、稳定 editor-facing 组件面不拥有DOM 翻译、属于slate-dom的浏览器事件语义、app 拥有的 inline 策略。Borrow NowLexical 的 core 与 React 包拆分参考LexicalComposer.tsxReact 拥有权保持显式与 editor 核心分离。当前仓库slate-react的稳定 editor-facing 表面是Slate、EditableBlocks、Editable、useSlateSelector、useSlateStatic这与「React 只做运行时接线」的定位一致。ProseMirror「React 不在核心」的硬边界ProseMirror 核心里没有 React这种「缺席」本身就是一种架构声明强化了 v2 的包拆分。RejectLexical 的useStateuseLayoutEffect订阅模型参考useLexicalSubscription.tsx当前 v2 坚持使用useSyncExternalStore语义这是正确选择。这也是slate-react走「selector-first、overlay locality、默认不触发 broad rerender」路线的原因见 master-roadmap.md Tranche 6 的 React runtime locality 要求。ProseMirror 没有 React 运行时叙事不能以此为由把slate-react规格写得含糊v2 应当比 ProseMirror 更显式。LaterLexical 的按 tags/dirty sets 显式 on-change 过滤参考LexicalOnChangePlugin.ts作为后续「派生非紧急 UI」的细化。更锋利的 stable-vs-advanced 表面切分对比 Lexical 的 React 包与当前 v2 proof 时代导出。3.4slate-history事务感知的历史End-state 定位拥有事务感知的撤销单元、重做单元、merge/save 边界、历史型编辑器的显式 reset/load 边界不拥有DOM 行为、React 生命周期、历史契约之外的 app 迁移策略。Borrow NowProseMirror 的选区书签严肃性参考history/src/history.ts历史系统应把选区恢复当作一等公民而不是事后附加。这在当前仓库的实现印证是packages/slate/src/slate-history/下的history.ts定义undos/redos批次结构与HistoryApi的undo/redo与with-history.tswithHistory插件跟踪 editor 的操作历史。Lexical 的历史对变更类别的感知参考lexical-history/src/index.ts历史语义绑定「更新的含义」而非仅绑定「经过的时间」。RejectProseMirror 的全套 branch/item 压缩机制好系统但对当前替换候选阶段太重。Lexical 的 tag 密集型历史契约作为立即必须项不合适好细化错时机。LaterProseMirror bookmarks作为撤销/重做选区行为最强的后续细化目标。Lexical 式 update tags仅当当前 reset/undo/redo 语义需要更细的分组规则时。3.5slate-browser证明基础设施End-state 定位浏览器测试 harness、editor-first 的 Playwright helpers、浏览器侧证明的 lane 拥有权不拥有产品 editor API、通用 driver 抽象、框架中立测试幻想。当前仓库中它的稳定表面是slate-browser/core、slate-browser/browser、slate-browser/playwright三个子路径以及ready作为被维护的 setup 契约。Borrow Now从 ProseMirror 不直接借测试基础设施它的价值在此是「架构压力」而非浏览器测试 helper。把 Lexical 当作提醒浏览器侧证明应驱动真实更新流而不是合成的手挥式测试。Reject通用多后端测试抽象目前只有一个真实后端在第二个后端出现之前不模仿更宽泛的框架 harness 层。把slate-browser变成产品 APIProseMirror 与 Lexical 都强化了「这是支撑基础设施不是编辑器运行时表面」。Later更丰富的 lane 过滤 / 事件打标间接受 Lexical 的 update tagging 启发但仅当当前浏览器 lane 噪音大到值得做时。四、扫描底线什么变了、什么没变附录用三组结论收尾这份「底线声明」是本次扫描最重要的纪律条款。ProseMirror 仍然强化的方向事务纪律transaction disciplineclipboard 边界拥有权clipboard boundary ownership选区书签严肃性selection-bookmark seriousness。Lexical 仍然强化的方向不可变提交更新模型immutable committed update model包拆分纪律package split discipline后续 transaction/history 元数据想法React 订阅设计中「应当拒绝什么」。现在要变的路线图应显式把 ProseMirror 当作slate-dom与slate-history细化的更强参考源把 Lexical 当作slate事务/更新压力与后续slate-react/history 细化想法的更强参考源。坚决不变的三条红线不把核心本体论转向 ProseMirror 或 Lexical——Slate v2 的核心仍以 Slate 的数据模型与公开操作约束为基准不重开包拥有权——五个包的分工transaction-first 核心 / DOM 边界 / React 运行时 / 事务感知历史 / 证明基础设施保持冻结不让slate-browser通用化——在第二个真实后端出现之前不做通用多后端抽象。从当前仓库看这三条红线与 master-roadmap.md 的包顺序slate→slate-history→slate-hyperscript→slate-dom→slate-react外加早期加入的slate-browser完全一致先钉死核心事务模型再依次关闭历史、DOM、React 运行时证明基础设施始终保持「ready-first」的辅助定位。五、把方法迁移到你的项目一份可复用的接缝扫描清单本次扫描的价值不止于 Plate 项目内部。任何正在做编辑器重构、或要在多个富文本方案之间做技术选型的团队都可以复刻这套方法。完整流程总结如下。先列接缝再找文件不要按「包」漫游源码而是先定义 36 个你最关心的架构接缝事务模型、历史语义、剪贴板边界、扩展机制、运行时订阅是通用五件套再为每个接缝精确映射 13 个源文件。对每个接缝做三方对照把两个候选实现的对应文件并排读记录「它们各自是怎么解决这个接缝的」落到一张「实现 × 接缝」矩阵。按包输出三级决策以你现有架构的包为行以「borrow now / reject / later」为列逐格填写。borrow 必须能指出具体吸收点reject 必须说明理由通常是「架构好但时机不对」或「与我们的数据模型约束冲突」later 必须给出触发条件。写一条底线声明明确写出「什么变了、什么不变」尤其是三条不变红线——不推翻自己的核心本体论、不重开包所有权、不让支撑性基础设施越界变成产品 API。让附录永远低于队列扫描结论只用于给决策施压永远不替代主路线图一旦主队列更新先同步控制文档再继续下一个包这正是 master-roadmap.md Review Rule 的要求。六、进一步阅读本次扫描的执行计划2026-04-06-slate-v2-prosemirror-lexical-roadmap-scan.md决策附录的完整归档版本含五包逐条决策与文件引用package-end-state-roadmap.md当前权威路线图与包顺序master-roadmap.md架构契约参考architecture-contract.mdslate核心包源码packages/slate/srcslate-history的实现印证history.ts 与 with-history.ts【免费下载链接】plateRich-text editor with AI and shadcn/ui项目地址: https://gitcode.com/GitHub_Trending/pl/plate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Plate 项目 Slate v2 技术选型扫描：ProseMirror 与 Lexical 五大接缝的借 / 拒 / 延决策指南
Plate 项目 Slate v2 技术选型扫描ProseMirror 与 Lexical 五大接缝的借 / 拒 / 延决策指南【免费下载链接】plateRich-text editor with AI and shadcn/ui项目地址: https://gitcode.com/GitHub_Trending/pl/plate本文是 Plate 项目 Slate v2 研发路线中的一份技术选型研究报告核心主题是在 Slate v2 重构过程中如何围绕transaction/update 模型、history/bookmark 语义、clipboard 边界、extension/plugin 组合、React 运行时订阅模型这五个接缝seam对 ProseMirror 与 Lexical 两个成熟编辑器进行定向源码扫描并据此为slate、slate-dom、slate-react、slate-history、slate-browser五个包给出「借borrow/ 拒reject/ 延later」三级决策。读完本文你将掌握这套跨编辑器架构比较的方法论、扫描结论的完整决策矩阵以及每个决策在当前仓库源码中的印证位置。一、背景为什么需要对 ProseMirror 与 Lexical 做定向扫描Slate v2 是 Plate 项目对 Slate 编辑器的现代重构方向其核心哲学是「继承 Slate 的数据模型与公共操作约束但不盲从任何第三方」。在重构的关键节点上团队选择对业界两个最有代表性的编辑器——ProseMirror 与 Lexical——做一次新鲜的、聚焦的代码扫描fresh focused code scan目的不是模仿或移植而是用它们检验自己的架构决策是否站得住脚。这场扫描的原始计划记录在 2026-04-06-slate-v2-prosemirror-lexical-roadmap-scan.md其结论沉淀为 package-end-state-roadmap.md 的附录该文件现已被归档为历史参考文档。当前路线图的权威真相以 master-roadmap.md 为准。1.1 五个被扫描的接缝seam所谓「接缝」是指编辑器架构中子系统之间的职责分界点也是最容易产生架构漂移的地方。本次扫描锁定五个接缝接缝要回答的核心问题transaction/update 模型状态变更如何被表达、暂存、提交变更是否可追踪、可回放history/bookmark 语义撤销/重做如何划分批次选区在历史操作后如何恢复clipboard 边界序列化、解析、内部元数据应该住在哪一层extension/plugin 组合扩展机制是核心内置还是插件注入时机是否成熟React/runtime 订阅模型React 运行时如何订阅编辑器状态会不会引发全局重渲染1.2 为什么挑这两个项目对比ProseMirror以严格的 transaction 纪律、插件系统、DOM 权威DOM authority over state著称适合检验 Slate v2 的「事务化核心 显式 DOM 桥接」路线。Lexical以不可变 editor state、自定义 reconciler、React 包拆分著称适合检验 Slate v2 的「不可变提交快照 selector 优先订阅」路线。两者恰好覆盖了 Slate v2 最关心的两个压力方向因此扫描结论被明确写入路线图ProseMirror 是slate-dom与slate-history细化方向的更强参考源Lexical 是slate事务/更新压力以及后续slate-react/history 细化想法的更强参考源见 package-end-state-roadmap.md 的「Appendix Bottom Line」。二、扫描方法五个阶段与两份文件清单计划文档把整个扫描组织为五个阶段前两个阶段是「读源码、画地图」后三个阶段是「收敛结论、落进文档」在prosemirror仓库中为五个接缝逐一映射精确源码文件在lexical仓库中为五个接缝逐一映射精确源码文件为slate、slate-dom、slate-react、slate-history、slate-browser五个包提炼具体可吸收的要点以「borrow now / reject / later」三级分类修订路线图附录校验格式并总结变更。从仓库侧印证这一方法的是最终产物确实是一份「五包 × 三级决策」的附录且明确声明「用这份附录去给包级决策施压pressure package decisions但不要让它在优先级上凌驾于队列之上」。2.1 ProseMirror 侧被扫描的文件扫描计划只圈定与五个接缝直接相关的 5 个文件不做全仓库漫游文件对应接缝state/src/state.tstransaction/update 模型state/src/transaction.tstransaction/update 模型state/src/plugin.tsextension/plugin 组合history/src/history.tshistory/bookmark 语义view/src/clipboard.tsclipboard 边界2.2 Lexical 侧被扫描的文件Lexical 侧的文件清单更长因为它把事务、编辑器、reconciler、历史、剪贴板、选区、扩展、React 订阅拆分到了不同包文件对应接缝packages/lexical/src/LexicalEditorState.tstransaction/update 模型packages/lexical/src/LexicalUpdates.tstransaction/update 模型packages/lexical/src/LexicalEditor.tstransaction/update 模型packages/lexical/src/LexicalReconciler.tstransaction/update 模型packages/lexical-history/src/index.tshistory/bookmark 语义packages/lexical-clipboard/src/clipboard.tsclipboard 边界packages/lexical-selection/src/index.tsclipboard 边界选区子系统packages/lexical-extension/src/LexicalBuilder.tsextension/plugin 组合packages/lexical-react/src/LexicalComposer.tsxReact/runtime 订阅模型packages/lexical-react/src/useLexicalSubscription.tsxReact/runtime 订阅模型packages/lexical-react/src/LexicalOnChangePlugin.tsReact/runtime 订阅模型三、五包决策矩阵借什么、拒什么、延什么这是全文的核心。五个包各自拥有独立的「Borrow Now / Reject / Later」三段式结论任何新提交的代码切片都必须能落进其中一格否则就属于「漂移」。3.1slate事务优先的文档核心End-state 定位拥有文档语义、操作模型、事务执行、不可变提交快照、运行时身份、显式替换/重置入口不拥有DOM 翻译、浏览器事件语义、React 运行时策略。Borrow Now现在就借ProseMirror 的事务形态纪律参考state/src/state.ts与state/src/transaction.ts保持「一个持久 editor 状态 一个显式 transaction 对象 一条 apply 路径」。这对应到当前仓库就是 master-roadmap.md Tranche 3 确立的公开生命周期层级editor.read读、editor.update写边界、原始 editor 方法灵活变更 API、事务拥有的目标新鲜度、EditorCommit作为本地运行时真相。Lexical 的不可变 editor-state 压力参考LexicalEditorState.ts与LexicalUpdates.ts提交态保持不可变把「更新」当作独立的分阶段单元。这与当前仓库packages/slate的提交快照契约committed snapshot contract方向一致。Reject现在拒绝ProseMirror 的核心内置插件定义状态参考state/src/plugin.ts「好架构错时机」。v2 核心不应在替换候选稳定之前重新打开插件模型。这一点在 package-end-state-roadmap.md 的slate一节被明确列为「Intentionally Latermiddleware/plugin phase pipeline」。Lexical 的定制 reconciler 模型参考LexicalReconciler.ts离 Slate 的数据模型与公开操作约束太远。Later以后再说Lexical 的 update-tag 词汇表参考lexical-history/src/index.ts与LexicalUpdates.ts作为事务元数据transaction metadata的细化方向。ProseMirror 的插件事务钩子参考plugin.ts仅当engine.md中的 middleware/end-state 方向后续被复活时才考虑。3.2slate-dom浏览器边界拥有者End-state 定位拥有 DOM point/path 转换、DOM selection 桥、clipboard 浏览器边界、嵌套 editor 与 shadow/iframe 边界规则、真正属于浏览器层的 composition/input 传输不拥有React hooks、运行时订阅、editor 语义。Borrow NowProseMirror 的显式 clipboard 边界参考view/src/clipboard.ts序列化、解析、内部元数据都住在 DOM 边界而不是散布在 React 层。当前仓库的印证是packages/slate-dom的ClipboardBridge与DOMBridge它们正是这条「显式浏览器边界」主张的实现见 package-end-state-roadmap.md 中slate-dom的「Done Now」与 Proof Gates。Lexical 的 clipboard selection 拆分拥有权参考lexical-clipboard/src/clipboard.ts与lexical-selection/src/index.ts选区与剪贴板是严肃的浏览器子系统不是事后补丁。RejectProseMirror 式的「DOM 权威于状态」Slate v2 已经选择了「提交态核心快照 显式 DOM 桥接」不采纳 view 栈中那种 DOM 对状态的全面控制。Lexical 的全浏览器拥有栈形态有用但与 Lexical 的 node/reconciler 模型耦合太深不能直接导入。LaterProseMirror 式更丰富的 clipboard 上下文元数据参考data-pm-slice处理仅当当前 fragment 元数据被证明太弱时。Lexical 选区子系统思路仅当当前 DOM selection 压力暴露出真实缺口时。3.3slate-reactReact 19.2 运行时End-state 定位拥有快照驱动运行时接线、selector 订阅、稳定 editor 实例语义、React 中的显式替换/重置消费、DOM 桥周围的 React 生命周期、稳定 editor-facing 组件面不拥有DOM 翻译、属于slate-dom的浏览器事件语义、app 拥有的 inline 策略。Borrow NowLexical 的 core 与 React 包拆分参考LexicalComposer.tsxReact 拥有权保持显式与 editor 核心分离。当前仓库slate-react的稳定 editor-facing 表面是Slate、EditableBlocks、Editable、useSlateSelector、useSlateStatic这与「React 只做运行时接线」的定位一致。ProseMirror「React 不在核心」的硬边界ProseMirror 核心里没有 React这种「缺席」本身就是一种架构声明强化了 v2 的包拆分。RejectLexical 的useStateuseLayoutEffect订阅模型参考useLexicalSubscription.tsx当前 v2 坚持使用useSyncExternalStore语义这是正确选择。这也是slate-react走「selector-first、overlay locality、默认不触发 broad rerender」路线的原因见 master-roadmap.md Tranche 6 的 React runtime locality 要求。ProseMirror 没有 React 运行时叙事不能以此为由把slate-react规格写得含糊v2 应当比 ProseMirror 更显式。LaterLexical 的按 tags/dirty sets 显式 on-change 过滤参考LexicalOnChangePlugin.ts作为后续「派生非紧急 UI」的细化。更锋利的 stable-vs-advanced 表面切分对比 Lexical 的 React 包与当前 v2 proof 时代导出。3.4slate-history事务感知的历史End-state 定位拥有事务感知的撤销单元、重做单元、merge/save 边界、历史型编辑器的显式 reset/load 边界不拥有DOM 行为、React 生命周期、历史契约之外的 app 迁移策略。Borrow NowProseMirror 的选区书签严肃性参考history/src/history.ts历史系统应把选区恢复当作一等公民而不是事后附加。这在当前仓库的实现印证是packages/slate/src/slate-history/下的history.ts定义undos/redos批次结构与HistoryApi的undo/redo与with-history.tswithHistory插件跟踪 editor 的操作历史。Lexical 的历史对变更类别的感知参考lexical-history/src/index.ts历史语义绑定「更新的含义」而非仅绑定「经过的时间」。RejectProseMirror 的全套 branch/item 压缩机制好系统但对当前替换候选阶段太重。Lexical 的 tag 密集型历史契约作为立即必须项不合适好细化错时机。LaterProseMirror bookmarks作为撤销/重做选区行为最强的后续细化目标。Lexical 式 update tags仅当当前 reset/undo/redo 语义需要更细的分组规则时。3.5slate-browser证明基础设施End-state 定位浏览器测试 harness、editor-first 的 Playwright helpers、浏览器侧证明的 lane 拥有权不拥有产品 editor API、通用 driver 抽象、框架中立测试幻想。当前仓库中它的稳定表面是slate-browser/core、slate-browser/browser、slate-browser/playwright三个子路径以及ready作为被维护的 setup 契约。Borrow Now从 ProseMirror 不直接借测试基础设施它的价值在此是「架构压力」而非浏览器测试 helper。把 Lexical 当作提醒浏览器侧证明应驱动真实更新流而不是合成的手挥式测试。Reject通用多后端测试抽象目前只有一个真实后端在第二个后端出现之前不模仿更宽泛的框架 harness 层。把slate-browser变成产品 APIProseMirror 与 Lexical 都强化了「这是支撑基础设施不是编辑器运行时表面」。Later更丰富的 lane 过滤 / 事件打标间接受 Lexical 的 update tagging 启发但仅当当前浏览器 lane 噪音大到值得做时。四、扫描底线什么变了、什么没变附录用三组结论收尾这份「底线声明」是本次扫描最重要的纪律条款。ProseMirror 仍然强化的方向事务纪律transaction disciplineclipboard 边界拥有权clipboard boundary ownership选区书签严肃性selection-bookmark seriousness。Lexical 仍然强化的方向不可变提交更新模型immutable committed update model包拆分纪律package split discipline后续 transaction/history 元数据想法React 订阅设计中「应当拒绝什么」。现在要变的路线图应显式把 ProseMirror 当作slate-dom与slate-history细化的更强参考源把 Lexical 当作slate事务/更新压力与后续slate-react/history 细化想法的更强参考源。坚决不变的三条红线不把核心本体论转向 ProseMirror 或 Lexical——Slate v2 的核心仍以 Slate 的数据模型与公开操作约束为基准不重开包拥有权——五个包的分工transaction-first 核心 / DOM 边界 / React 运行时 / 事务感知历史 / 证明基础设施保持冻结不让slate-browser通用化——在第二个真实后端出现之前不做通用多后端抽象。从当前仓库看这三条红线与 master-roadmap.md 的包顺序slate→slate-history→slate-hyperscript→slate-dom→slate-react外加早期加入的slate-browser完全一致先钉死核心事务模型再依次关闭历史、DOM、React 运行时证明基础设施始终保持「ready-first」的辅助定位。五、把方法迁移到你的项目一份可复用的接缝扫描清单本次扫描的价值不止于 Plate 项目内部。任何正在做编辑器重构、或要在多个富文本方案之间做技术选型的团队都可以复刻这套方法。完整流程总结如下。先列接缝再找文件不要按「包」漫游源码而是先定义 36 个你最关心的架构接缝事务模型、历史语义、剪贴板边界、扩展机制、运行时订阅是通用五件套再为每个接缝精确映射 13 个源文件。对每个接缝做三方对照把两个候选实现的对应文件并排读记录「它们各自是怎么解决这个接缝的」落到一张「实现 × 接缝」矩阵。按包输出三级决策以你现有架构的包为行以「borrow now / reject / later」为列逐格填写。borrow 必须能指出具体吸收点reject 必须说明理由通常是「架构好但时机不对」或「与我们的数据模型约束冲突」later 必须给出触发条件。写一条底线声明明确写出「什么变了、什么不变」尤其是三条不变红线——不推翻自己的核心本体论、不重开包所有权、不让支撑性基础设施越界变成产品 API。让附录永远低于队列扫描结论只用于给决策施压永远不替代主路线图一旦主队列更新先同步控制文档再继续下一个包这正是 master-roadmap.md Review Rule 的要求。六、进一步阅读本次扫描的执行计划2026-04-06-slate-v2-prosemirror-lexical-roadmap-scan.md决策附录的完整归档版本含五包逐条决策与文件引用package-end-state-roadmap.md当前权威路线图与包顺序master-roadmap.md架构契约参考architecture-contract.mdslate核心包源码packages/slate/srcslate-history的实现印证history.ts 与 with-history.ts【免费下载链接】plateRich-text editor with AI and shadcn/ui项目地址: https://gitcode.com/GitHub_Trending/pl/plate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考