企业官网建设流程全解析

plate / Slate v2 编辑器全局系统目标：以职责分层的九层架构蓝图

【免费下载链接】plateRich-text editor with AI and shadcn/ui项目地址: https://gitcode.com/GitHub_Trending/pl/plate

导读

本文是 plate 仓库中 editor-global-systems-objective.md 的技术解读。该文档回答的不是"slate-browser下一步做什么"，而是更高一层的问题：如果从本地最强的参考项目中偷取最好的想法，同时不把 Slate 拼成一个缝合怪，整个未来的编辑器系统应该长什么样。本文会逐层拆解这套"按职责分层"的九层目标栈，结合仓库内 slate-v2 迁移现状、架构契约、浏览器证明层 与 跨仓库架构研究 等文档，给出每一层的归属（Owner）、目标（Target）、参考（Primary references）与纪律（Rule）。读完你可以掌握：为什么编辑器系统必须分层、每一层该吸收哪些外部项目的核心纪律、以及哪些"抄作业"是类别错误。

强主张：按职责分层，而不是做成巨型包

文档的 Strong Take 非常明确：最好的未来系统是按职责分层的（layered by responsibility）。

它明确反对四类"巨型化"倾向：

• 一个巨大的编辑器包（one giant editor package）
• 一个巨大的插件 API（one giant plugin API）
• 一个巨大的测试运行器（one giant test runner）
• 一个巨大的服务桶（one giant service bucket）

理由来自所有最强参考项目的共同惩罚逻辑：

这套"惩罚清单"其实是架构判据：一个设计好不好，看它在哪里被打脸。这些项目各自的纪律恰恰是 plate 未来分层系统每一层的养料，具体吸收方式记录在 slate-v2-plate-v2-architecture-research.md 中（该研究文档为每条外部想法分配了adopt-now-for-slate-v2、adopt-later-for-slate-v2、better-fit-for-plate-v2、interesting-but-reject四类归属）。

目标栈：九层平面详解

下文按文档顺序逐层展开。每层都包含四要素：Owner（归属包）、Target（目标）、Primary references（主要参考）、Rule（纪律红线）。

1. Document Engine Plane（文档引擎层）

• Owner：slate-v2
• Target：文档语义（document semantics）、操作（operations）、事务（transactions）、不可变已提交快照（immutable committed snapshots）、运行时身份 sidecar（runtime identity sidecar）
• Rule：核心保持无聊且强壮；绝不允许产品 UX、服务协议或布局引擎向下渗漏（leak downward）

这层的定位是"文档真相的唯一持有者"。它在当前仓库中的落地形态可以从 architecture-contract.md 看到：editor.read是连贯读边界，editor.update是写边界，事务（transaction）是内部执行模型，且明确"child-count chunking stays dead"——不再用子节点计数分块这种旧方案，印证了文档"让核心保持无聊且强壮"的纪律。仓库 packages/slate 目录下create-editor.ts、slate-dom.ts、slate-history等文件也体现了核心包与 DOM、历史子系统的物理分离。

外部参考中，ProseMirror 的state/src/state.ts（持久化不可变 EditorState）与 Lexical 的LexicalEditorState.ts（提交后不可变的编辑器状态）是这层的主要对标对象；两者在 slate-v2-plate-v2-architecture-research.md 中均被归类为对slate-v2的"采纳"级证据（ProseMirror 的包拆分被标记为adopt-now-for-slate-v2）。

2. Runtime And Rendering Plane（运行时与渲染层）

• Owner：slate-react-v2
• Target：selector-first 订阅、语义岛（semantic islands）、活跃编辑走廊（active editing corridor）、默认对大文档安全（large-doc-safe）的姿态、足以避免大范围重渲染污泥（broad rerender sludge）的更新元数据
• Rule：活跃编辑信任实时 DOM（trust live DOM for active editing）；只有偏离活跃路径（off the active path）时才使用确定性规划辅助（deterministic planning helpers）

这一层的核心矛盾是"实时 DOM 体验"与"确定性规划"的边界：光标、选区、输入法组合这些活跃路径上的行为必须信任浏览器实时 DOM，不能把测量或规划引擎塞进去；而语义岛、遮挡（occlusion）等渲染策略则属于可规划的范畴。当前仓库的运行时代码约束同样在 architecture-contract.md 的 Part IV（React Runtime Spec）中：语义岛、活跃走廊、遮挡、selector-first 读取和 overlay kernel 的优先级高于旧的子节点分块或宽泛快照读取。

3. Browser Proof Plane（浏览器证明层）

• Owner：slate-browser
• Target：分层测试车道（layered test lanes）、以示例挂载为真相（example-mounted truth）、把选区与剪贴板当作一等工件（first-class artifacts）、Chromium-first 的 IME 证明、显式留出后续跨浏览器与性能车道
• Rule：浏览器证明是它自己的系统，不是附属件（not a sidecar）

这一层在仓库中有完整的配套文档体系：slate-browser/overview.md 定义了 Layer 0（核心快测）→ Layer 1（DOM 契约测试）→ Layer 2（示例集成测试）加 Lane A（IME/合成）等分层框架；next-system-move.md 则给出了明确的下一步：把openExample(...)打磨成真正的 readiness 契约，然后用它构建 renderer/input-policy gauntlet（零宽字符、IME 敏感空状态、哨兵文本周围的选区规范化）。参考列表中的 Lexical 测试编排、edix 与 rich-textarea 的 Vitest 契约车道、Premirror 的测试策略文档，都是"浏览器证明独立成系统"的证据来源。

4. Projection And Derived-Data Plane（投影与派生数据层）

• Owner：未来的plate-v2
• Target：规范化投影存储（normalized projection stores）、显式索引（explicit indexes）、增量派生视图（incremental derived views）、关系感知的注解/评论/语义投影
• Rule：编辑器真相留在slate-v2；语义投影与关系感知视图位于其上（live above it）

核心参考是 TanStack DB 的规范化集合与 live queries。对应研究见 slate-v2-plate-v2-architecture-research.md 的 TanStack DB 小节：它被评价为"最强的投影/索引参考"，其显式索引、增量派生视图、薄框架绑定（useSyncExternalStore风格的 live-query 订阅）是未来 plate 语义层"保持模块化而不变成烂泥"的最佳模板；但研究同时强调不要把 TanStack DB 变成编辑器真相源——这正好呼应本条 Rule。

5. Execution Pipeline Plane（执行管线层）

• Owner：未来的plate-v2
• Target：一个中央执行枢纽（central execution hub）、交易所式的阶段（exchange-like stages）、显式排序（explicit ordering）、可选能力，但不做一个巨型中间件桶
• Rule：不要插件汤（no plugin soup）、不要隐藏副作用（no hidden side effects）、不要未文档化的执行顺序（no undocumented execution order）

参考是 urql 的 overview 与 graphcache。研究文档中 urql 小节给出的可复用教训非常具体：中央 client/event hub、显式 operation/result 管线、可选 exchanges 而非硬编码行为、关于转发与排序的硬规则（如"不丢弃未知操作""同步优先、异步殿后"）。这些正是"执行管线"层要内化的纪律，也是未来 plate 语义管线的架构压力。

6. Hosted Feature And Protocol Plane（宿主特性与协议层）

• Owner：未来的plate-v2
• Target：按特性注册表（per-feature registries）、显式宿主边界（explicit host boundaries）、协议形态的语义服务（protocol-shaped semantic services）、能力协商（capability negotiation）、可取消且带版本号的请求流（cancellable, versioned request flows）
• Rule：语义服务应该说文档、位置、编辑、诊断与能力（documents, positions, edits, diagnostics, capabilities）；它们不应该说 Slate 内部实现（not Slate internals）

参考是 VS Code 的 agent/session 协议与 test/perf 入口、LSP 的 overview 与 initialize 契约。研究文档中 VS Code 小节的要点是：用 per-feature registry 而不是一个巨型插件接口、宿主/进程边界显式化、按特性类型逐个适配 provider；LSP 小节则强调协议纪律——initialize 恰好一次并先做能力协商、版本化文档同步、拉取式诊断、completionItem/resolve懒加载、取消与ContentModified处理。这些是未来 plate 语义服务层"不说编辑器内部模型"的契约蓝本。

7. Layout And Measurement Plane（布局与测量层）

• Owner：未来的plate-v2；狭义上slate-react-v2提供选择性规划支持
• Target：确定性测量（deterministic measurement）、布局作为独立引擎、文档真相之上的页面感知组合（page-aware composition）、可选屏外规划几何（offscreen planning geometry）
• Rule：绝不让活跃光标、选区或输入法组合流经测量引擎；确定性测量只用于规划、分页、遮挡与滚动稳定

参考是 Premirror 架构与 Pretext 的prepare → layout拆分及 accuracy/benchmark 命令。研究文档中 Premirror 的EditorState → snapshot → measure(pretext) → compose → LayoutOutput架构被评价为"页面感知编辑系统的正确形状"，其核心结论是页面组合应该建在文档真相之上、而不是渗入编辑器核心；Pretext 的两阶段模型（prepare一次性分段测量 +layout廉价重复计算）则为确定性测量提供了原语级证据，研究明确其最匹配未来布局/分页/虚拟化层。

8. Lightweight Surface Plane（轻量表面层）

• Owner：未来的plate-v2
• Target：原生输入优先的小表面（native-input-first small surfaces）、装饰型 textarea（decorated textareas）、仅在问题真正需要时才用轻量 contenteditable
• Rule：不要把完整的 Slate 硬塞给小文本问题（do not force full Slate onto tiny text problems）

参考是 rich-textarea 与 edix。研究文档对 rich-textarea 的结论极具操作性：如果问题是"纯文本 + 装饰"，就用原生文本控件 + 覆盖视觉层（textarea + mirrored backdrop），彻底避开 contenteditable 混乱；对 edix 则吸收其 DOM 选区序列化为框架无关快照、剪贴板显式边界等"适配器纪律"。此外 Open UI Richer Text Fields 与 EditContext API 也进入研究视野：前者是平台侧让原生输入更强大的提案压力，后者是未来slate-dom-v2输入归属的候选平台原语，但研究强调 EditContext 并不能自动解决选区映射、拼写检查、剪贴板、无障碍与历史。

9. Productization Plane（产品化层）

• Owner：未来的plate-v2
• Target：强打包（strong packaging）、清晰的扩展目录（clear extension catalog）、让系统"上手很快"的文档与示例
• Rule：打包胜利很重要；但它们仍不能成为腐蚀下层架构的理由

唯一参考是 Tiptap（作为产品化基准），对应研究文档 editor-architecture-candidates.md。研究对 Tiptap 的定性是：它快主要是因为它把 ProseMirror 打包得极好（单依赖 PM 包装、干净的 React 包、巨大扩展目录、headless-but-batteries-included 路径），这对plate-v2极其重要，但对slate-v2而言只是提醒——不要把产品打包的胜利误当成引擎/运行时胜利。

综合目标：整个系统应该呈现的样子

如果这套方案走对，未来系统应当表现为六条清晰的职责分工：

1. slate-v2拥有文档真相与事务；
2. slate-dom-v2拥有浏览器传输与 DOM 桥；
3. slate-react-v2拥有订阅、渲染姿态与运行时策略；
4. slate-browser用分层车道证明浏览器面向的真相；
5. 未来的plate-v2拥有投影、服务、产品扩展与布局感知体验；
6. 轻量原生表面在可能时脱离完整编辑器栈。

这就是"全局系统"的最佳目标形态。从仓库现状看，第 1、2、3、4 条正处在真实推进中：slate-v2迁移已在 overview.md 中明确为"最终态项目"，tranche 1（Bun 根/工具链图、Bun 测试归属、包清单构建归属）与 tranche 2（React 19.2.5、Next 16.2.4、TypeScript 6.0.3、包源码 HMR）已完成，tranche 3 正把packages/slate重构为原生事务引擎与 snapshot/store-first API；slate-browser则已具备core/browser/playwright的公开拆分与一整套test:slate-browser:*根命令（见 slate-browser/overview.md）。

我们不该做什么：八类类别错误

文档明确列出不该瞄准的目标，这些全部是"把别家整层搬进自家某一层"的类别错误：

• Lexical 的整体引擎模型（不要整个照搬）
• ProseMirror 的整体本体论（不要整个照搬）
• 把 Tiptap 的产品层塞进 Slate 核心
• 把 Premirror 的布局引擎塞进活跃编辑运行时
• 把 TanStack DB 当作编辑器真相源
• 把 urql 的 exchanges 直接塞进slate-v2
• 把 VS Code 的扩展托管塞进核心编辑器包
• 为浏览器本地编辑原语引入 LSP 式协议

研究文档与这套"不该做"清单完全同构：例如 TanStack DB 与 urql 的主要价值被明确判给plate-v2（better-fit-for-plate-v2），而不是用来改写slate-v2核心；LSP 的教训是"语义服务不该说你编辑器的内部节点模型"；use-editable 的 DOM 真相 + 变更回滚技术则被直接标记为interesting-but-reject，因为它与slate-v2数据模型优先的锁定约束相悖。

当下影响：下一步工作纪律

因为这是目标栈，接下来的工作应当保持纪律：

1. slate-browser：强化openExample(...)的就绪度（readiness），并证明 zero-width / IME / 空状态（empty-state）gauntlet。这与 next-system-move.md 的推荐完全一致：先把OpenExampleOptions围绕 readiness 语义收紧，再加 readiness 敏感的浏览器回归，然后才向外分支到test:slate-browser:cross、test:slate-browser:perf、test:slate-browser:accuracy。
2. slate-v2/slate-react-v2：继续兑现渲染器/输入策略接缝（renderer/input-policy seams），之后再兑现脏信号纪律（dirty-signal discipline）。
3. 未来plate-v2研究：把跨域导入（cross-domain imports）转化为显式设计工作，具体对象是：投影（projections）、执行管线（execution pipelines）、按特性注册表（per-feature registries）、协议形态语义服务（protocol-shaped semantic services）、布局/测量托管（layout/measurement hosting）。

底线：从每一层偷对的东西，让每一层待在它的车道上

文档的 Bottom Line 是对全文的收束：最好的未来系统不是"挑一个最好的编辑器仓库然后复制它"，而是同时具备：

• ProseMirror 级的包纪律
• Lexical 级的运行时与浏览器测试纪律
• Premirror + Pretext 的测量与组合纪律
• TanStack DB 的投影纪律
• urql 的管线纪律
• VS Code + LSP 的服务纪律
• rich-textarea / edix 的轻量表面纪律
• Tiptap 的产品化纪律

用文档原话收尾：从每一层偷对的东西（steal the right thing from each layer），让每一层待在它的车道上（keep each layer in its lane）。这套全局系统目标既是 plate 未来slate-v2/slate-react-v2/slate-browser/plate-v2分层演进的北极星，也是任何想要构建下一代富文本编辑器的团队可以直接复用的架构判据。

【免费下载链接】plateRich-text editor with AI and shadcn/ui项目地址: https://gitcode.com/GitHub_Trending/pl/plate