手搓编辑器核心逻辑到深处要评估换社区方案

更新于 2026-06-28

**Markdown 实时渲染编辑器一旦核心逻辑是自己手搓、且越补越多，长期维护成本会失控；到某个深度应优先评估社区方案，而不是继续手搓。** 判据是「你已经在重写一个成熟编辑器内核的职责」。

补充（2026-06-28 修正）：换社区方案不等于直接用它的默认规则。 编辑器要拆成两层看：底层内核（光标/选区/撤销/快捷键/markdown 语法识别）和live preview 规则层（隐藏 **、把 - 换成圆点这类显示规则）。前者几乎都该复用成熟内核，后者才是手感差异所在。Atomic Editor 本身也是基于 CodeMirror 6 做的——问题不是 CodeMirror 不行，而是 Atomic 在 CodeMirror 之上加了它自己的一套 live preview 规则，和想要的 Obsidian 手感不一致。所以正确做法是：直接用 CodeMirror 6 自己搭 live preview 规则层，而不是放弃 CodeMirror、也不是照单全收 Atomic 的默认规则。

手搓范围越深，边界 bug 越多

不只是把 **粗体** 渲染成粗体，还包括：表格直接可编辑、checkbox 可点击、图片直接显示、链接点击、当前行显示原始 Markdown 而其他行渲染、中文粗体/斜体兼容补丁、表格光标移动与增删行列、DOM 内容回写 Markdown。这些都很容易出边界 bug，尤其表格。

评估优先级

方案特点
@atomic-editor/editor最贴合：CodeMirror + Obsidian 风格实时渲染，支持表格/图片/任务列表，Markdown 原文是唯一数据源
codemirror-live-markdown更像 CodeMirror 插件，可细粒度替换 livePreview.ts，但版本偏 alpha，稳定性待验
codemirror-markdown-hybrid功能全但社区信号弱，核心编辑器不建议押上
MDXEditor / Milkdown更成熟，但迁移成本大，体验会更像富文本而非 CodeMirror Markdown

结论：手搓方向能跑，但长期难维护；先用 Atomic Editor 做小实验，看能否覆盖当前最难的场景（表格）。

选型是「内核 + 规则层」的组合，不是二选一

把上面这张表按两层重读，判断会清楚很多：

层判断
底层编辑内核不要手搓，用成熟的（CodeMirror 6 等）
live preview 规则层这才是决定「像不像 Obsidian」的地方，值得自己搭

因此「评估社区方案」的结论要加一句限定：先评估它能否替换内核，再评估它的规则层要不要留。 一个方案内核很好但规则层不合手，正解是保留内核、替换规则层，而不是整个换掉或整个照抄。

认知演化：2026-06-25 把 Atomic Editor 列为「最贴合」，隐含假设是「整体采用」；2026-06-28 拆出两层后发现真正的冲突只在规则层，结论从「选哪个现成方案」变成「复用内核、自建规则层」。

相关