Halo 默认编辑器还是 Markdown，先回答这三个问题

之前还在 QQ 群里问大家都在使用什么编辑器，使用 Halo 也有段时间了，所以整理了这篇文章。

编辑器选错了，改起来比换主题麻烦得多。

我以前也没当回事，新建文章时右上角那个下拉框点一下就过去了。后来把官方文档翻了一遍才反应过来，那一下定的是这篇文章往后以什么形态待着。结论反而简单，别按手感选，按几年后还拿不拿得回来选。

先问自己三件事

对比文我看了不少，一上来就甩功能表，看完更拿不定主意。毛病出在那些维度各答各的问题上，摆一起当然打架。

后来我只留了三问。

问自己	其实在问	往哪走
这批文章以后要在别处打开、改、版本管理吗	源文本归谁	答「是」，就让源留在本地
内容里有没有公式、图表、复杂代码块，或者反过来有大量拖拽排版	内容复杂度	按内容形态挑扩展能力
你写字主要发生在后台、本地编辑器，还是脚本里	工作流位置	写在哪儿就留在哪儿，别硬搬

这三问跟 Halo 没关系。换 WordPress、Typecho，或者任何一个既存原稿又存成品的后台，照样是这三下，源在谁手里、内容长什么样、人坐在哪儿写。Halo 只是把答案具体成了几个插件名，和一条叫 rawType 的字段（标记原始内容是什么格式）。

急着要答案的，直接跳「三类人怎么选」那节。下面几节是我把账拆开算的过程。

三个问题分别指向三条不同路线，先定源在哪儿、内容什么形态、人在哪儿写，工具只是最后一步

一篇文章其实存了两份（raw 与 content）

这事儿我是翻官方文档才看明白的。

Halo 官方 editor:create 文档里，插件想注册一个新编辑器，得交一个 EditorProvider，里面明晃晃摆着 raw、content、rawType 三样。raw 收原始内容，content 收渲染后的内容，示例里那行 emit("update:content", marked(...)) 就是现场演示，纯文本进 raw，渲染成 HTML 交回 content。

也就是说，你写的那份和给访客看的那份，Halo 是分开存的。选编辑器，选的是前一份长什么样。用默认富文本，raw 是结构化文档或 HTML；装了 Markdown 插件，raw 就是纯文本；content 两边都是 HTML。

两件事，别混。

我一开始也以为 Halo 导出只有 HTML，拿不到 Markdown。后来把存储形态和导出能力掰开，发现不是这么回事。我点开「文章导入导出」插件页（v1.2.5）看了，功能说明头一条就是「快速导出文章为 markdown 或者 html 文件」；「内容助手」（v1.9.1，要求 Halo ≥ 2.26.0）更直接，「支持转换为 Markdown 文件导出」，Markdown 和富文本还能互转。

可内容助手这页顶上还挂着一行警告，我抄了下来。「目前格式转换并不能完全保留原格式，部分语法可能在不同的编辑器中有不同的表现，建议谨慎使用。」

能导出，但拿到的是转换产物，当初写的那份源拿不回来。content 是渲染结果，从它往回推 raw，中间必然丢东西，这一步躲不掉。2023 年 issue #4625 的官方回复里也问过一句，默认编辑器存的是富文本 HTML，这种内容该怎么导出，那是 2.9 前后的语境；今天插件能转了，有损这件事没变。

还有一条常被拎出来当现状，说 1.x 迁 2.x 会丢 Markdown 源。官方归档文档确实白纸黑字写着「迁移之后会丢失 Markdown 编辑器的内容，仅保留已渲染的 HTML 内容」，可那份文档开头就标了「最新的迁移插件可能已经不适用于当前文档」，前提是「Halo 2.0 暂时没有 Markdown 编辑器」。现在 2.26 以上一堆插件摆着，这条我只能当历史读，拿它吓今天才装博客的人，不合适。

所以「不可逆」没有把你锁死到连文件都吐不出来的程度。要紧的是你当初交出去的是哪一份 raw，后面想改主意，得走一次有损转换，还得自己盯着哪儿变了。

一篇文档同时存 raw 与 content 两份，转换是从 content 反推 raw，能导出拿到的是转换产物，中间那道转换有损

Halo 默认编辑器不是凑合用的

把它当「没装插件前的将就选项」，后半程会一直误判。

默认编辑器本体是 npm 上的 @halo-dev/richtext-editor，2.27.0，built with Tiptap + ProseMirror，包描述还专门警告「与 Halo 紧耦合，不适合通用编辑器场景」。它长在 Halo 里，本来就不适合单独拎出来用。想给它加东西，走 default:editor:extension:create 扩展点，返回类型直接来自 Tiptap，Halo 另给 5 个自家接口，工具栏、Slash Command、悬浮菜单、工具箱、拖拽菜单。官方文档还记着，2.26.0 起补了运行期组件元数据，后面那句我看了两遍。「AI Agent 是目前的主要消费者」。

这句得替它说句公道话。常见结论是「要自动化、要让 AI 处理，就得 Markdown」，可官方正在把富文本这边的结构也做成机器能读的。它补上的是机器读得懂这一头，至于你能不能拿回源文本，它不管，两码事。

选它，换到的是站内那一整套，拖图片、挂附件、超链接卡片，官方每次加功能你直接就能用。代价是内容跟 Halo 的文档模型绑得紧。这笔账不亏，只是得知道自己在换什么。

官方那六种 Markdown 写法，其实就三条路

官方那篇《在 Halo 中使用 Markdown 写作的 6 种方式》（2026-04-12）列得挺全，编辑器插件、Markdown 内容块、内容助手批量导入、VS Code 插件（微软那款代码编辑器）、Obsidian 插件、Halo CLI（官方命令行工具）。文末那张「如何选择」表只按场景列，不判哪条更好。

按「人坐在哪儿写」收一下，就三条路。

后台直接写是一条路，装 Vditor 或 ByteMD（应用市场里的 Markdown 编辑器插件）这类插件，装完在新建文章右上角切换，预览发布一条线。代价是能力全看那个插件，作者不更了你也就到顶。

本地写、Halo 只当发布口是第二条，VS Code 插件、Obsidian 插件、halo post import-markdown、内容助手批量导入都算。源在自己硬盘上，能进 Git、能多平台发、能脚本批量；代价是图片和路径自己管，多一道推送。

第三条是富文本为主、局部插 Markdown 块，不动既有排版，只给某一段加语法。可那个块是插件自己渲染的，公式这类要特定渲染器的东西，块里不一定生效。

写字的地方在哪儿就别硬搬，搬家成本比选插件高，不划算。

那些对比项，各自在答不同的问题

能搜到的维度一大把。我按三问归了归位，多数「谁更好」的争吵根本不在同一个问题上。

内容复杂度这问看扩展，默认编辑器是平台级，Tiptap 生态加 5 个自家接口；Markdown 那边是应用级，能力由你装的那个插件自己定。

人在哪儿写这问看性能和自动化。GitHub 上有人提过 2.19 插入表格直接卡死（issue #6626），也有人把缩进、列表这些别扭一条条列出来（issue #7492），跟版本绑得很紧，纯文本管线轻一些，但我不敢据此说谁一定更快。自动化上，Markdown 天然能 diff、能脚本批量；默认编辑器 2.26 起补的是平台内的机器可读元数据，路子不一样。

源归谁这问看渲染和信任边界。默认编辑器所见即前台那份产物；Markdown 要过「源 → 渲染器 → HTML → 主题」好几道，中间哪一段没接上，前台就跟预览对不上，这是管线长度带来的风险，我并没有实测过哪条线真的出过故障。粘过来的内容容易带着内联样式跟主题打架，纯文本进去样式归主题管，源头干净。安全这块我只能给判断，富文本的 HTML 由 Halo 统一过滤，Markdown 那边靠你用的外部工具和渲染管线各自把关。

上面几类反馈说不好是不是版本带来的，我没敢写成硬结论。能当硬事实用的是官方页面上的接口名、版本号，和那句转换警告。

找到你最在意的那一问，只看那一块，其余全是噪声。

三类人怎么选（三条路和什么时候别选）

该给答案了。下面按三问分完类给落点，排序先后不代表好坏。「什么情况下别选」比推荐什么更值钱。先认一个名字，ToolBench（2023 年的社区插件），往文章里插自定义 DOM 标签，即网页里那些元素节点，还带自己的样式。它的应用市场条目这次已经打不开了（快照 2026-11-13），只剩论坛帖和 GitHub 仓库还能查到，见文末来源。你没听过很正常，从老站迁过来还留着它的人才会撞上。

你是	选	具体动作	什么情况下别选
只在后台写、图文为主、没打算搬家	默认富文本编辑器	直接用，偶尔贴代码或说明就加 Markdown 内容块插件	以后要批量迁走、要版本管理、通篇公式图表
技术写作、公式图表多、但不想离开控制台	后台 Markdown 编辑器插件	先看下面三条硬约束，再定 Vditor 还是 ByteMD	还留着 ToolBench 这类改页面结构的老插件、Halo 版本偏低、不想多维护一个插件
已有本地写作流、多平台发布、批量导入或 AI 生成	本地 Markdown + 官方集成推送	VS Code 插件 / Obsidian 插件 / `halo post import-markdown`，Halo 只当发布口	所有图片都必须在后台拖拽管理、不愿意碰路径

三条硬约束，逐条给实锤。

头一条，Vditor 插件页和 GitHub 上的 README（仓库首页）都写着，跟 ToolBench 同时用，数学公式、脑图、图表、流程图、甘特图、时序图、五线谱全渲染不出来，原因是它改了页面结构，「所以不会修复」。翻它自己的发布帖就明白改了什么，给文章前后插自定义 HTML。两边对不上的根子在这儿，作者明说不给修。

第二条，ByteMD（1.10.0）要求 Halo ≥ 2.26.0，公式也不是装上就有，得再装 plugin-katex，还得在 KaTeX 设置里配好 DOM 节点，编辑器和文章里才都出得来。

第三条，坑的不止 Vditor。「文章导入导出」那个插件页也标了「与插件 ToolBench 一起使用时存在不兼容的问题，导致文章无法查看」。这两条说明都是当年写下的；从老站迁过来还留着它的，先把这个变量排掉，犯不着装一堆插件再回头排查。

这俩怎么挑，我偏向不玩脑图、甘特图这类花样的人选 ByteMD，官方 halo-sigs 维护，轻；要那些图表能力就上 Vditor，代价是暗色模式只跟随系统，还得记着别跟改页面结构的插件混装。这是我的判断，不是榜单。

还有一类人这表没装下。已经用默认富文本写了几十篇、现在想留纯文本的，办法有两条，内容助手能逐篇互转，文章导入导出插件能批量导出 md，但都是转换产物，官方那句警告就是给这条路预备的。别整站动手，先挑三篇最简单、没有复杂排版的试一遍，看得失能不能接受，再决定动不动存量。

最后个笨办法比看十篇对比文管用，拿一篇不重要的稿子，完整走一遍「写 → 发 → 导出 → 在别处打开」。哪一步开始变形，那就是你这条路的真实边界。