我在 横评的上篇 中，对将近 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 是真不太行。