再过不到半年，Markdown 就要诞生满二十年了。
不过，要在 2023 年的今天找出一款简洁好用的 Markdown 编辑器，选项数量似乎还不如十多年前。当时，（众筹跑路之前的）Mou 风头正劲，iA Writer、Byword 等日后出名的作品也大量涌现并快速发展。如今，市场上更多的是那些「支持 Markdown 语法」的笔记类软件，而少见专精于 Markdown 编辑的新作品；老牌软件有不少选择往大而全的方向转型，也有很多则干脆进入维护模式、以至停更。
这种趋势是可以理解的。毕竟，作为一种标记语言，Markdown 更多是一种「方法」，而非目标本身，开发上能做的空间和差异度毕竟有限；从业务角度来说，「编辑器」也没有「笔记」和「知识管理」那样好讲故事，更不好收钱。
即使如此，Markdown 编辑器并没有失去存在的意义。有的时候，我们需要的确只是一个能简单敲几段话、改几行字、能简单排版的输入框，或者只是想看看一个现成文件的预览效果、导出成其他格式分享出去。对于这种需求，动用那些复杂的笔记工具既不方便、也无必要。
但在迈出寻找的脚步前，首先有必要明确标准——什么样的 Markdown 编辑器才算「好」？
什么是「好」的 Markdown 编辑器
正如以 Mou 为代表的经典 Markdown 编辑器一般采用「左编辑、右预览」的两栏布局，评价一款 Markdown 编辑器的功能也可以从编辑和预览两个板块入手；它们分别对应着编辑器和 Markdown 解析器1这两个核心部件。
编辑器方面，一般可以从以下角度考察编辑器功能的完善程度：
- 快捷格式操作：包括适用于桌面端的快捷键和适用于移动端的快捷工具栏；
- 语法高亮：包括高亮 Markdown 标记自身和代码块内的其他语言代码，以及高亮识别是否迅速、准确；
- 查找替换：宜支持正则表达式；
- 标题相关功能：包括目录生成和跳转，以及按标题折叠内容等；
- 自动补全：包括针对链接、图片、表格等繁琐语法的快捷输入方式，以及括号等成对标记的补全等；
- 自定义样式：包括选择字体、字号和主题配色等。
一个相对有争议的功能是「即时预览」（live preview）——直接在编辑器中显示 Markdown 预览效果，仅在光标焦点所在行显示原始的 Markdown 标记。对此，支持者认为可以省去另行显示预览的步骤和空间，看起来更加美观；反对者则认为违反了 Markdown 的设计意图，也不利于批量编辑，何况 Markdown 标记本身已经足够直观了。当然，双方都没有绝对的对错，站哪边更多取决于用例和偏好。
不难看出，这些功能中很多在代码编辑器中都是现成的。的确，Markdown 作为一种轻量标记语言，所需的功能集本就介于普通文本框和完整的代码编辑之间。因此，可以看到大量 Markdown 编辑器项目选择直接套用 Ace、CodeMirror 和 Monaco 等现成的代码编辑器框架，以便「免费」获得这些功能。当然，由此产生的代价就是脱离相应平台的 UI 框架，容易破坏软件的「原生」感；能否缝合得尽量自然，则也是对开发者设计能力的一种考验。
解析器的坑则更多。如你可能已经感觉到的，Markdown 有一套看似简单易学，实则「四分五裂」的语法。Gruber 基于 Perl 开发的原版 Markdown 既不严谨也不完善——非常规缩进、空行和夹用标记的解析结果经常带来「惊喜」，表格、脚注、删除线、代码块高亮这些在今天不支持简直没法用的功能，也都付之阙如。
这给各种「扩展」和「变种」Markdown 语法留下了大量的想象空间：IANA 根据 RFC 7763 标准建立的登记册就收录了多达 12 个 变种。尽管如今凭借着 GitHub 的影响力，其基于 CommonMark 扩展而来的 GitHub Flavor Markdown (GFM) 似乎成了最流行的标准，但五花八门的实现方式往往并不能做到严格遵守。这都加剧了「巴别塔」式的现状。
因此，在选择 Markdown 编辑器时，对其解析器支持的语法不应过分贪多求全。相比之下，渲染基础样式的准确和高效才是更重要的。「创新」得越多，往往也就意味着偏离标准越远，写出的文件越可能不与其他工具兼容。一般而言，建议选择一个遵循 GFM 的软件就够了。在此之外的语法（例如公式、图表等）已经超出了 Markdown 解析器的职能，即使支持，也是通过「外包」给相应的外部组件（例如 MathJax 和 Mermaid）进一步渲染实现的，实用性和显示效果都一般，也不能应对真正专业的需求。
这里，我做一个了包含常见 Markdown 基础和扩展语法（以及一些「雷区」）的测试文件，在 GitHub 上的预览除了不支持高亮标注和上下标外都是正确的，你可以在测试感兴趣软件时用作参照。
其他一些考虑因素包括：
- 导出格式支持。尽管不少产品会宣传自己的导出格式之丰富，但对于 Markdown 而言，唯一「天生」支持的导出格式其实只有不带任何样式的「裸」HTML。除此之外的字体、颜色等视觉风格则是由另行搭配的样式规则控制，而 PDF、Word 等额外导出格式则都是虚拟打印或调用外部转换器得到的。受这些方法的自身局限和开发者的精力所限，很少有编辑器能导出满足一些最起码的排版标准的效果。因此，不建议对导出功能抱太高期待，以工整易读（GitHub 的默认样式同样可以作为一个参照）、有自定义空间为标准即可。如果有更高的要求，额外花点功夫折腾 CSS 和 Pandoc 大概是免不了的。
- 更新频率。虽然说更新频率高一般是好事，但对 Markdown 编辑器的版本更新应当有合理的预期——这显然不是一类需要经常推陈出新的软件，无须因为仅仅隔几个月甚至一年没有更新，就担心软件是否已经过时。当然，必要的维护性更新还是有必要的，例如适配新版操作系统或新设备的特性，或者升级所依赖的第三方库版本；这也可以视为一种「存活确认」，表示开发者对项目的持续兴趣。
在上述讨论的基础上，以下是我们经过对比试用，认为目前各平台上最值得一试的 Markdown 编辑器。需要说明的是：
- 为了减少「选择困难症」，本文针对平台只重点介绍一个综合权衡下最值得尝试的，然后简单提及其他可以考虑的选项。这当然是具有主观色彩的，欢迎补充和提出不同意见。
- 本文只考察支持从文件系统直接打开 Markdown 文件，并且能将编辑的文件重新保存回文件系统的 Markdown 编辑器。因此，采用专有「文档库」，将文件存储在沙箱或数据库中，仅通过导入和导出功能才能接触文件系统的软件，均不属于本文的讨论范围。
- 本文考察的是免费软件，特别是开源软件。但这绝非因为本文认为 Markdown 工具不值得付费，而是因为支持 Markdown 的付费软件要么把重点放在笔记管理等编辑以外的功能上，从而不属于本文的讨论范围，要么本文介绍的免费选项足以对其竞争力构成合理的挑战。
