精读《对 Markdown 的思考》

Markdown 即便在 2022 年也非常常用，比如这篇文章依然采用 Markdown 编写。

但 Markdown 是否应该成为文本编辑领域的默认技术选型呢？答案是否定的。我找到了一篇批判无脑使用 Markdown 作为技术选型的好文 Thoughts On Markdown，它提到 Markdown 在标准化、结构化、组件化都存在硬伤，如果你真的想做一个现代化的文本结构编辑器，不要采用 Markdown。

概述

Markdown 流传甚广，甚至已成为我们的第二语言。Markdown 最早的解析器由 John Gruber 在 2004 年基于 Perl 编写发布，那时候 Markdown 只有一个目的，即为了方便网络写作。

网络写作必须基于 HTML 规范，而 HTML 规范对大部分人上手成本太高，因此 Markdown 就是基于文本创建的更易理解，或者说上手成本更低，甚至傻瓜化的一种语法，而要解析这个语法需要配套一个解析器，将这种语法文本最终转化为 HTML。

而数字化发展到今天，Markdown 已不再适合当下的写作场景了，主要原因有二：

1. Markdown 不再适合当下富交互、内容形态的编写。

2. Markdown 纯文本的开发体验不再满足当代开发者日益提高的体验需求。

首先还是从 Markdown 思想开始介绍。

Markdown 的核心思想

Markdown 最大优势就是好上手，不需要接触 HTML 这种复杂的嵌套语句（虽然对程序员来说 HTML 也简单到处于鄙视链底端）。原文抽象了三个优势：

1. 基于文本的合适抽象。虽然 HTML 甚至代码都是文本，但 “合适” 这个词很重要，即任何文本都可以是 Markdown，只要加一点点小标记就能描述专业结构，学习成本极低。

2. 有大量生态工具。比如语法解析器、高亮、格式转换、格式化、渲染等工具完备。

3. 编辑内容便于维护。比如 Markdown 很方便作为源码存储，而其他格式的富文本可能并不方便在源码里维护。

如果把 Markdown 与数据库表结构做比较，那数据库的理解成本真是太高了。

但是在如今后端即服务的时代，数据库访问越来越轻松，甚至出现大量如 AirTable 等 SAAS 产品将结构化数据快速转化为应用，其实接触了这些后才真正发现，结构化数据对开发者有多重要。Markdown 用来写写文章还是不错的，但用来表达逻辑结构最后一定会引发灾难后果，原文作者的团队就深受 Markdown 技术选型的困扰，被迫解决大量远超预期的难题。

如果真的要在 Markdown 的坑越