编辑器与只读渲染要分层

更新于 2026-09-22

**编辑场景用完整编辑器引擎（Milkdown/ProseMirror），只读场景用轻量自研渲染器 —— 不要拿编辑器去渲染只读内容。**

笔记编辑用 @milkdown/crepe（底层 ProseMirror）是对的；但对话回复、分享页这类只读场景不该复用它，三个硬伤：

  1. 实例开销：一个 Milkdown 实例 = 一个完整 ProseMirror 编辑器（schema/transaction、光标选区、输入法、undo 栈）。对话页几十条消息各起一个实例，内存与初始化耗时都会爆。轻量渲染器每条消息只是一次纯函数解析。
  2. 流式天敌：编辑器期望「拥有」文档状态，流式 delta 只能整篇 setContent 重灌 → 全量重建文档树 + DOM diff → 闪烁卡顿。它本来就不是为 token 流设计的。
  3. 包体积：编辑器全家桶很大，只读场景不该背这个运行时。

分层方式：

场景需求用什么
笔记编辑双向、可交互、光标/选区完整编辑器
分享页展示单向、只读轻量渲染器
对话回复单向、只读、高频流式轻量渲染器（与分享页共用一条管线）

判据：看这个场景要不要「写」和「光标」，而不是看它显示的是不是 markdown。 多个只读场景应共用同一条渲染管线，编辑器专心做编辑 —— 这也是「引擎不做建模器」的同一取向：各自干最擅长的事。

相关：引擎不做建模器、手搓编辑器核心逻辑到深处要评估换社区方案、兼容fallback会让内容重复渲染

相关