富文本编辑器选型对比与 Vditor 方案确定

概述

富文本编辑器是后台系统里典型的"重依赖组件"，一旦接入，后续替换成本通常不低。所以在写第一行集成代码之前，更值得先做一轮工程化选型：在内容模型、集成成本、维护状态、UI/UX 体验与项目工程约束之间权衡，而不是简单地列几个编辑器名字。本文对比 Quill、TOAST UI Editor、Vditor、Milkdown 四款方案，并修正课程录制时的几处时效性判断，最终说明为什么在当前项目诉求下 Vditor 是综合最均衡的主推方案。

学习目标

• 厘清"HTML 富文本优先"与"Markdown-first"两种内容模型的差异，理解它如何决定选型。
• 掌握 Quill、TOAST UI Editor、Vditor、Milkdown 各自的定位、强项与适用边界。
• 能对课程口述里过时的维护状态判断做时效性校正，不照搬旧结论。
• 理解"选型结论要放回当前项目上下文"，而非看单个功能点绝对胜出。
• 知道最终推荐 Vditor 是基于"综合能力最均衡"，而非某个特性绝对第一。

一、选型是在做内容模型与工程约束的权衡

富文本编辑器会影响很多维度：偏 HTML 富文本还是偏 Markdown 文档流、纯所见即所得还是支持 Markdown 实时输入、是否容易集成到 Vue 3、是否有现成插件生态、是否支持表格/公式/流程图/脑图/甘特图等扩展、是否适合 CDN external、组件封装、暗黑模式与移动端适配。

因此这一节本质上是在做"工程化选型决策"。编辑器是重依赖组件，后面要替换代价高，所以选型时不能只看功能列表，更要看项目自己的工程边界。如果项目未来要支持知识库、文章系统、文档中心，Markdown 路线通常更值得优先考虑——它天然适合长期存档、版本化和技术文档化。

二、Quill：轻量 HTML 富文本，非 Markdown-first

Quill 的定位非常清晰：轻量、富文本、所见即所得、集成简单。从官方 Quickstart 看，接入方式直接，甚至支持 CDN 初始化：

import Quill from "quill"

const quill = new Quill("#editor", {
  theme: "snow",
  modules: { toolbar: true },
})

这让它很适合运营后台的基础内容录入、对排版要求不复杂的文章编辑、希望快速接入富文本能力的场景。但它的关键差异是：并不是以 Markdown 输入体验为核心。像 Typora 那种"直接打 Markdown 语法并即时转义"的体验，不是 Quill 的默认强项。也就是说，Quill 更适合 HTML 富文本输出，而不是 Markdown-first 方案；如果产品核心是文档写作，它未必最贴切；但若看重 CDN external 或轻量集成，接入门槛确实低。

三、TOAST UI Editor：双模式完整，但"停更"判断已过时

TOAST UI Editor 的能力很完整：Markdown 模式、WYSIWYG 模式、实时预览、Scroll Sync、表格、插件能力。它非常适合一边写 Markdown 一边看渲染、既要源码输入又要富文本体验、需要 GFM 风格文档编辑的场景。官方给出的 Vue 用法也很直接：

<template>
  <Editor initialEditType="markdown" previewStyle="vertical" />
</template>

<script setup lang="ts">
import { Editor } from "@toast-ui/vue-editor"
</script>

这里要修正课程口述中的一个重要时效性判断：原文说它"停更""没有 Vue 3 官方方案"，但按当前官方页面，@toast-ui/vue-editor 仍被官方列为 Vue wrapper，GitHub Releases 也仍有更新。这不代表它就一定最适合本项目，但说明"项目已停更、Vue 3 完全没人管"这个判断已不准确。选型时要区分"功能很强"和"是否适合当前项目工程体系"这两件事。

四、Vditor：三种模式 + 中文友好 + 扩展面广

课程最终重点推荐的是 Vditor，这个判断有逻辑。从官方 README 看，它明确支持三种模式：所见即所得（WYSIWYG）、即时渲染（Typora-like）、分屏预览（Split View）——这正好覆盖了前面几款编辑器的优势形态。此外它还支持数学公式、脑图、流程图、时序图、甘特图、图表、五线谱。

初始化方式同样简洁：

import Vditor from "vditor"

const editor = new Vditor("editor", {
  mode: "sv",
  height: 480,
})

从综合能力看，它非常适合后台文档编辑、知识库内容录入、带 Markdown 能力的富文本表单、需要图表/流程图/公式的技术内容编辑。对中文使用者来说，默认体验和资料可获取性通常更友好。如果你的项目既要 Markdown，又想保留所见即所得体验，Vditor 是很有竞争力的方案。

五、Milkdown：插件化编辑器框架，接入成本更高

Milkdown 当前官方定位是 plugin-driven 的 WYSIWYG Markdown editor framework。这意味着它不是单纯的"现成编辑器"，更偏一个可扩展的编辑器框架，适合深度定制，更强调插件驱动和能力拼装。它颜值高、扩展性强、Markdown 路线清晰，这些都成立。

但课程之所以没把它作为首选，关键不只是功能，而是工程边界：集成成本、打包方式、构建策略、对 external/CDN 的诉求。结论不是"Milkdown 不好"，而是它更像框架而不是开箱即用小组件——选它就意味着接受更高定制度和更深接入。如果项目只是要一个稳定好用的后台编辑器，不一定需要一开始就走框架型方案；只有当编辑器本身要作为重点能力深度定制时，Milkdown 的价值才真正凸显。

六、为什么最终选 Vditor：综合均衡而非绝对第一

把诉求叠在一起看：要方便集成、功能足够丰富、颜值高、bug 少、更新频繁、兼顾 Markdown 与富文本体验。再看前面几款：Quill 轻量好接但 Markdown 弱；TOAST UI Editor 模式完整但要评估 Vue 3 与工程接入；Milkdown 非常强但更像框架、接入维护成本更高；Vditor 模式完整、能力丰富、中文友好、功能覆盖广。

所以课程最终把 Vditor 拉进视野，是一个"综合评分最高"的结果，而不是某个特性绝对第一。最终推荐 = 更适合当前课程项目，不是否定其他方案。选型结论一定要放回当前项目上下文，没有一个编辑器能在所有维度绝对胜出。

七、四款编辑器对比速查

把前述维度收敛成一张表，便于快速回看各自定位：

这张表不是评分排名，而是提醒你：每款编辑器都有清晰的主场，选型时先把"项目要在哪个主场作战"想清楚，再对应选人。

八、落到本项目的具体决策

本项目的诉求可以归纳为：Markdown 能力、富文本体验、丰富扩展（公式/流程图/脑图/图表）、Vue 项目易接入、后续便于二次封装和业务接入。把这套诉求套到上面的对比里，Quill 在 Markdown 与扩展面偏弱，TOAST UI Editor 需额外评估工程接入，Milkdown 的框架型成本对本项目偏重，而 Vditor 在模式完整性、中文友好度和扩展覆盖面三项上最贴合。因此把它作为后续组件封装的基础方案——这是基于当前项目目标得出的结论，而非对其它方案的否决。

选型从来不是一次性动作。项目诉求会随阶段变化：早期可能只要一个能写 Markdown 的框，后期可能要协作、版本、导出。把编辑器收敛成一层可替换的封装组件（下一节开始做），正是为了将来即使换方案，业务层也不至于大改。封装层的存在，本身就是对"重依赖组件难替换"这一风险的对冲。理解这一点，后面两节围绕 Vditor 做的封装与配置面板，就不只是"接一个编辑器"，而是为整个内容编排能力打底座。

下一节将从零搭建 Vditor 基础组件，先把容器、实例与生命周期这三件事钉死，再逐步收敛默认配置与双向绑定。选型定方向，封装定骨架，两者缺一不可。

常见问题

延伸阅读

• 上一篇：原生 ECharts 组件封装、shallowRef 实例管理与自适应更新
• 下一篇：Vditor 基础组件封装、默认配置合并与 v-model 联动
• 相关：Vditor 配置面板联动、动态表单扩展与响应式示例页