我在 横评的上篇 中，对将近20款编辑器进行了一个初步的探索，然而这种“快速过一遍，凭主观印象”的方式不甚准确，故制定一些标准，来对它们进行一个更客观（但也免不了主观因素）的评价。

此部分横评覆盖了上篇中的所有Markdown编辑器——除了Microsoft Word这个来捣乱的。由于时间原因，测试项难免覆盖不完整，如果还有想了解的，可以在评论区留言，不过系统环境变化可能较大，不能保证结果完全可比较。

部分测试项在以下仓库开源：

TLDR

用一个Excel表格直观反映每项得分。没有考虑各项权重分配，并不能简单加和来得到最终结果。

基本信息

界面设计

首先映入眼帘的就是软件的界面，一个高颜值的界面能够带来愉悦感，而设计得当的交互能够提高使用的效率。当然这方面也和个人的感觉有很大的关系。

大部分编辑器都采用了较为简约的设计，以白色为主色调，在这方面Typora是当之无愧的标杆，主界面没有过于繁杂的元素，操作均收入顶栏，操作的分类安排也较为合理，能够很快找到想要的部分。但是也有很多编辑器简洁过了头，如Obsidian将很多常用操作都收进了右上角的菜单中，并没有很好的分类。WordMark将选项全都收进了按钮和Alt键菜单，这在macOS下可能无可厚非，但在Windows下十分别扭。VNote和Arya的编辑器界面有一定相似性，但VNote的界面看起来就更杂乱。Joplin的界面相对来说不算简洁，但很高效。

批判一番Zettlr，按钮布置十分杂乱，学习成本极高；配色奇怪而压抑，没有设计感。不过QOwnNotes才是重量级，乱得实在用不下去。

开源

软件开源，就意味着可以审查它的源代码来确保没有危险，对其作出自己的修改以符合自己的需求，或是为这个软件的开发完善贡献自己的力量。

闭源软件有Typora、Obsidian、马克飞象和WordMark，而VS Code和IntelliJ IDEA只有核心部分开源。

费用

大部分是免费的，收费的有整个收费和部分功能收费两种。目前整个收费的只有Typora，而StackEdit、IntelliJ、Obsidian和马克飞象有部分功能收费。StackEdit提供了Docker自托管的选项，同步云服务有一定困难，但导出PDF是免费功能。

Joplin是一朵奇葩，它的同步服务器也是开源并开放自建的。

值得注意的是，IntelliJ单作为一个Markdown编辑器的话，是免费的；而如果想获得基础Java支持之外的功能，则需要收费。

持续更新

持续更新的能力能在一定程度上代表适配系统新特性的能力。比如Linux下，新版本Electron才对Wayland有基本的支持，考虑到Markdown编辑器大量采用Electron，这个特点也很重要。当然，很久不更新不代表表现就会差，一直会更新也不代表表现会好。

Haroopad和WordMark的最后更新时间停在了数年前，而StackEdit和Notable也已经有一年没更新了。其余的在今年都有更新的记录。

跨平台与云同步

桌面端跨平台

这里的桌面端跨平台，涵盖的是Linux、Windows和macOS。有几款竟然神奇地支持了FreeBSD，但鉴于用户实在太少，不强求。

有Electron或者Qt加持的应用基本都能够正常支持跨平台，而网页端应用更不必说，凡是有浏览器的地方，就能跑起来。鉴于Windows版本一般没啥兼容性问题，笔者主要装了Linux版本试试。 Notable的Linux版本有时候跑不起来，而Wordmark的Linux版遇到了经典依赖问题——装不上（当时使用的是Ubuntu 22.04）。

另外还有一个异端Marker，仅支持Linux和FreeBSD。由于笔者没有Mac，此处也没有纳入许多Mac独占的优秀编辑器。

移动端跨平台

这部分网页端应用大获全胜，毕竟Electron又不支持移动端。除了网页端的几个应用之外，就只有VS Code、Joplin和Obsidian做了移动端支持。Obsidian和Joplin在移动端是原生应用，而VS Code用了另一种方案：直接把应用搬上了网页（vscode.dev，或GitHub Codespaces)。

这三款支持移动端的App一致性都做得很好。

云存储接入

少数编辑器有自己的云存储空间，并作为增值服务售卖，如Obsidian；其他的编辑器（如StackEdit）则会依赖第三方的云存储，如OneDrive和Google Drive等。

LetsMarkdown似乎使用了一种不同的方案。出于协作需求，它会将用户的文档默认保存至服务器。

WordMark和StackEdit面向的是blogger，也就接入了WordPress、Medium和GitHub平台发表文章，就算它是个同步吧。

Obsidian、VS Code和IntelliJ还提供了Git插件，但鉴于不是自带Git客户端，此处不算作接入云存储。

QOwnNotes接入了Nextcloud和ownCloud等云存储服务，对自托管的服务支持较好。

Joplin支持官方云、自建同步服务、OneDrive等同步服务。

编辑体验

指示功能

在主界面上常驻一些字数统计之类的功能是有必要的，而太多了则会适得其反。

测试中，WordMark的字数统计完全无法正常使用，其目录也因为无法正确识别标题而难以使用。

有目录的有Typora、Obsidian、MarkText、Notable、Typedown。

有字数统计的有VS Code、Typora、Obsidian、StackEdit、MarkText、Zettlr、Haroopad、QOwnNotes、Typedown。

图片管理

Markdown是纯文本格式，无法内嵌图片，所以需要额外的图片解决方案。有的会将图片存放在某个目录下，而有的支持上传至第三方云平台。

存放于工作区内的有Obsidian、Typora、MarkText、Zettlr、IntelliJ、VNote、Notable、QOwnNotes、Joplin，一般都是粘贴时自动保存到工作区的特定文件夹中。

能够上传到云端平台的有WordMark、Typora、MarkText。

剩余的仅能插入外链。

导出体验

一般来说都是导出PDF，所以此处重点体验PDF导出的质量，对其他格式只作数量要求，反正一般也是Pandoc实现。

Notable和Marker不知道咋回事导不出，就算了。

PDF可自定义度

一些软件可以自定义PDF导出的格式，从单纯的页面设置、页面主题，到可自定义CSS。

支持多种内置主题的有StackEdit、MarkText、Typora，其中Typora一个非常强大的功能是可以使用CSS完全自定义主题。

支持设置一些页面参数的有Obsidian和MarkText。

PDF渲染质量

对于这一项，一般来说渲染没问题的都会得10分。值得注意的是，一些软件导出的PDF与预览有所不同，比如Zettlr导出后能够支持预览并不支持的规范。

Obsidian对数学公式的渲染匪夷所思，虽然支持TeX公式，但渲染出来字体竟然是黑体。

Dilinger虽有导出功能，但大量字符缺失，中文字符更完全无法显示。

VS Code和IntelliJ在无插件的情况下不支持导出。

QOwnNotes的情况有点奇怪，它会将Markdown符号一起导出，而非纯净的预览。这方面见仁见智，不过我给扣了分。

还有的PDF导出后竟然比软件内预览的兼容性更强……很怪。

其他格式数量

其实没啥好说的，能调用Pandoc的就有优势呗。

CommonMark 语法

CommonMark标准是对原版Markdown规定的细化，内含基础的Markdown语法，更适合作为一个基本的Markdown要求。

此部分的得分是能正常通过的测试项数量。通过数量多的一定代表好，但通过数量少的也不一定难用，因为其中也包含一些平常不会触及的corner case，而CommonMark也只是其中一个标准，并无强制性。

基本

此部分包含“字符与行”、“制表符”、“转义字符”、“实体和数字字符”这些方面。

WordMark最惨，即使是Electron，稍复杂的格式基本无法正常渲染。

叶块

此部分包含”ATX标题”、“设置文本标题”、“缩进代码块”、“围栏代码块”、“HTML块”、“链接引用”、“段落”等方面。

这里大部分编辑器没有得分的地方是paragraph部分。CommonMark要求两行之间间隔一行才能算作换行，而大部分编辑器并没有严格遵守，渲染出了5行（本应该是2行）。大部分情况下其实也可以不算一个问题。

“设置文本标题”部分出的问题也千奇百怪，有的只能识别一行标题，有的甚至识别不出标题。

Joplin避过了所有的坑，成为惟一一个全部通过的编辑器。

容器块

此部分包含“块引用”、“列表项”两个方面。

有的编辑器如马克飞象和Marker等，会直接将自定义序号替换成从1开始编号。

内联

此部分包含“代码块”、“强调和特别强调”、“链接”、“自动链接”和“图片”几个方面。“代码块”部分特增加了几个非传统热门语言。

此处着重说一下代码块。C的高亮应该是只要支持语法高亮就会包含的，而新兴的如Rust，以及没那么热门的Verilog/汇编则支持较少。Typora是唯一一个能支持汇编（assembly）渲染的编辑器，而大部分出现0.5分的编辑器都是因为语法高亮支持不全。

GFM 语法

GitHub也是使用Markdown语法较多的平台，它在一定程度上扩展了原版Markdown的语法，形成了GitHub Flavored Markdown标准，也有一定的影响力。

表格

绝大部分编辑器都不能正常渲染\|的转义符号，虽然不会将其识别为表格分隔符，但显示仍然是\|而不是期望的|。

待办列表

Marker成为了参测编辑器中唯一一个不支持待办语法的编辑器。

自动标题

GFM的自动标题相比于CommonMark添加了对没有任何外加标记的链接的直接识别。很少有编辑器能够将邮箱地址自动识别为mailto链接，大部分都较为保守，毕竟也有一定的误识别可能性。

图表

GFM定义了Mermaid、Geojson、Topjson和STL模型四种图表格式。都是基于代码块定义的。尴尬的是，哪怕表现最好的编辑器也只支持Mermaid，而后三种只有GitHub网页能正常显示。

后续可能会增加PlantUML等其他图表的测试？等有空再说吧。

数学公式

GFM定义了使用两个$符号的公式块、使用一个$符号的内联公式，以及使用代码块格式的公式定义。此外还借用了 这篇文章 中GitHub数学公式的一些bug。

性能

渲染较大规模文档的能力也是很重要的一个方面。这里使用从Project Gutenberg下载的《战争与和平》英文版（56.5万词，3MB），并转换为Markdown文件用于测试。对于能在Linux安装的编辑器，测试环境是Ubuntu 22.10开发分支，AMD Ryzen 7 4800H，24G内存，GeForce GTX 1650+NVIDIA闭源驱动。如果不能安装，使用Windows 11 22621.160。对于网页版编辑器，这里忽略平台不同的影响，均选择Firefox最新版本，使用浏览器任务管理器查看内存占用。

StackEdit最大支持打开约250KB的文档，剩余部分被截断，无法完成测试。Typora不支持打开此大小的文件。Zettlr查看时经常卡死无响应。Arya粘贴后直接卡死。Marker完全无响应。

打开时间

打开软件，从软件中的打开方式打开文档开始计时，到加载出正确渲染的文档内容。

VS Code的代码加载很快，几乎马上就能加载出来，但预览很慢。类似的情况也在类Typora的所见即所得的编辑器中出现，如果需要将整个文档渲染一遍，就会花很长时间。

内存占用

需要注意，网页端和原生应用的内存占用不能直接比较。网页本身的内存占用通常很小，许多浏览器本身动辄占用几百兆内存，而大部分Electron应用相当于再开了一个浏览器。

流畅度

将流畅度从0-10打分，很流畅则得10分，完全无法正常浏览则得0分。

v2ex网友说MarkText有性能问题似乎是真的，不过能打开也比Typora强了。

VS Code不知道吃了什么微软神油，编辑和浏览都巨流畅。

另记

Typora的数学公式渲染需要手动开启。

VS Code缺失的部分基本可以使用插件开启，如导出文档、Mermaid图表等。

哦忘了说了，Electron就是个垃圾。