Markdown即使到了2022年也很常用，比如这篇文章还是用Markdown写的。但是Markdown应该成为文本编辑的默认选择技术吗？答案是否定的。我发现一篇很好的文章ThoughtsOnMarkdown批评盲目使用Markdown作为技术选择。它提到Markdown在标准化、结构化和组件化方面存在缺陷。如果你真的想成为现代文本结构编辑器，请不要使用Markdown。概述Markdown如此广泛，它甚至已经成为我们的第二语言。Markdown最早的解析器是JohnGruber于2004年基于Perl编写并发布的，当时Markdown只有一个目的，那就是方便网络写作。网页写作必须基于HTML规范，而HTML规范对于大多数人来说上手成本太高，所以Markdown是一种基于文本创建的语法，更容易理解，或者说上手成本更低，甚至是愚蠢的。要解析这个语法，需要配备一个解析器，将这个语法文本转换成HTML。在数字化发展的今天，Markdown已经不适合现在的写作场景。主要有两个原因：Markdown已经不适合现在的富交互和内容形式的书写。Markdown纯文本的开发体验已经不能满足当代开发者日益增长的体验需求。首先我们从Markdown的思想说起。Markdown的核心思想Markdown最大的优点是简单易用，不需要接触HTML等复杂的嵌套语句（虽然对于程序员来说，HTML简单到处于链的最底层）鄙视）。原文抽象的三个优点：基于文本的适当抽象。虽然HTML甚至代码都是文本，但是“适合”二字很重要，即任何文本都可以是Markdown，只需一点标记就可以描述出专业的结构，学习成本极低。有大量的生态工具。比如语法解析器、高亮显示、格式转换、格式化、渲染等工具都齐全。编辑内容易于维护。例如，Markdown作为源代码存储起来很方便，而其他格式的富文本可能不方便在源代码中维护。如果拿Markdown和数据库表结构来比较，了解数据库的成本实在是太高了。然而在如今的后端即服务时代，数据库访问越来越容易，甚至出现了AirTable等大量SAAS产品，可以将结构化数据快速转化为应用。多么重要。Markdown用来写文章有好处，但是用来表达逻辑结构就不可避免地会导致灾难性的后果。原作者团队对Markdown技术的选择深感困扰，被迫解决了大量远超预期的问题。如果你真的想在Markdown的坑里越陷越深，就必须使用语法扩展来满足自定义需求。Markdown语法扩展最初，Markdown语法不支持表格。如果要使用Markdown绘制表格，只能使用原生的HTML标签：。当然，这也说明Markdown的本质是增强HTML的便利性。语法，我们可以将其用作HTML。然而，并不是所有的创作平台都支持

的语法，创作者常常为此烦恼。例如，一些平台会屏蔽原生的HTML语法，以确保内容体验的所谓“安全”或“一致性”，并且为了弥补画表能力的不足，这些平台往往会支持一些自定义的语法，更糟糕的是，它们并不支持。这是Markdown的语法扩展。Markdown有哪些扩展？例如：multiMarkdown、commonMark、GithubFlavoredMarkdown等。这里随便举个例子，比如标准的MD格式，其实第一行末尾要加两个空格换行，但是GFM取消了这个限制。这样虽然方便多了，但是也暴露了平台间规范不一致的问题，这让Markdown跨平台基本难免被坑。而我们是否有足够的精力去学习和记住各个平台扩展的语法？先不说能不能记住。首先，是否值得学习是一个问题。为什么在线写作平台需要占用作者的学习和认知成本，而不是试图简化写作过程？所以语法扩展看起来很美，但是站在一个写手的角度，或者整个互联网各个平台的角度，这种不规范的做法肯定是不靠谱的。没有用户认为你的平台有资格“教他语法”，除非你是微信、钉钉、飞书。原文中提到的一点是：作为一个写手，你不知道哪些语法在Markdown中可用，哪些不可用。标准规范中存在一些模糊的地方，导致开发者在实施时遇到各种纠结。原文还提到了一个语法扩展导致理解成本较高的例子：slack平台定制的mrkdown不支持[link](https://slack.com)来描述链接，而是使用语法。综上所述，Markdown语法的扩展应该是一件好事，但是没有标准导致了标准的泛滥，使得Markdown成为一个实际上没有标准的状态，整体上弊端更多。Markdown的目标用户群Markdown对自身的定位其实是很不明确的，这也导致了语法规范的缺乏确定性。最初，Markdown是一种面向熟悉HTML的人的标记语言，但后来它转向了面向开发者的用户群，因为开发者只想着扩展语法来满足更复杂的使用场景，而Markdown的原生语法无法适应更多以及更复杂的视觉展示形式。今天，Markdown的主要用户是开发人员和对代码感兴趣的人。这并不是说开发者有多喜欢它，而是说Markdown的受众变窄了。现在任何非开发者群体的文档编辑器都不会用Markdown，而是所见即所得的WYSIWYG（所见即所得）模式。这个转变的过程是痛苦的，但是现在，富文本编辑器不应该使用Markdown语法，而是所见即所得模式已经成为共识。简单来说，从段落到区块，从文章到应用，Markdown已经不适合当下HTML的丰富生态。它可以很容易地描述段落的标记语言。遇到丰富的交互组件块，不得不引入诸如MDX等方案，但这样的方案只适合程序员，根本无法移植。网络浏览的形式也从简单的文章演变为整体应用。这些应用程序具有复杂的布局、样式和交互。如果你尝试支持基于Markdown的扩展语法，你可能会发现直接使用原生HTML会更好。对结构化内容的需求从编程的角度理解为“组件重用”。Markdown的原生语法无法实现内容的复用。如果一定要复用内容，只能在每个地方重复写入，势必造成巨大的同步成本。例如，Jekyll提出了创建可重用变量的FrontMatter概念：---food:Pizza---

{{page.food}}

WYSIWYG编辑器不应该使用HTML作为底层数据结构，尽管浏览器确实使用HTML作为底层数据结构，但这并不意味着所见即所得的编辑器也可以做到这一点，这就是为什么浏览器只能提供从源代码到UI的输出，而不能提供从UI编辑到源代码的输出。反向输入。因为用户输入和HTML之间没有一对一的对应关系，所以存在很多歧义。例如，如果当前光标位于粗体和细体文本之间，那么下一个输入是否应该是粗体？从UI中看不到粗体标签。再者，如果HTML中存在冗余，其实当前光标位置已经被粗体标签包裹了好几层，只是因为光标所在的区域被另外一个style标签覆盖成了非粗体模式，再次进入时可能会跳出。覆盖范围再次变为粗体。这个过程是否满足用户的期望？从技术上讲，这种复杂的标签结构几乎无法处理，因为组合太多了。大多数现代编辑器以JSON格式存储数据结构，因为它结构化且易于检索。结构最重要的体现是生成的HTML结构可以稳定，即对于一个既是粗体又是红色的文本，必须用标签包裹，而不是用，也就是这种模式根本不把HTML当做结构化数据，自然不会有歧义。Markdown也是如此，它本身具有类似于HTML标签的歧义性，不适合作为底层数据结构来存储。密集抨击Markdown的文章不多，笔者也是看了才知道Markdown有这么多缺点。下面我就结合自己的经历说说Markdown的缺点吧。无奈不支持丰富交互的Markdown只能支持简单的HTML结构，无法描述逻辑块。Github上的Readmes大多是用图片来实现这些功能的，包括状态卡、构建结果、个人信息名片等，可惜交互能力还是太弱了。我觉得有一天Github应该引入Blocks这样的小块的概念，这样这些块就可以作为交互元素直接插入到Markdown中。MDX是否解决了Markdown的痛点？看似能完美兼容JSX和Markdown的MDX曾经是笔者的救命稻草，但这种方案的可移植性是一大痛点。这些组件只能在您部署的网站上使用。如果你想把文章发布到其他平台，完全没有必要。可能的。这只是作者的观点。从Markdown生态来看，MDX只是为程序员服务的，并没有解决其“方便上网写作”的使命，程序员最终会放弃MDX，转向开发所见即所得的编辑器来解决问题。Markdown到HTML的转换存在逻辑问题。Markdown本质上是一种从HTML中分离出来的文本表示结构。看起来解耦很优雅，但实际上会遇到很多不一致的地方。例如，如果连续点击多个空格会怎样？在Markdown中，它会变成一个带引号的块，那么如何显示多个空格呢？没人知道，可能需要查阅具体平台提供的附加语法才能搞定。这种情况一般使用方便，但细节无法定制，甚至超出用户控制范围的情况也会极大地伤害已经深入使用Markdown的用户。这时候，用户要么硬着头皮发明新的语法来解决这些漏洞，要么彻底放弃Markdown。结构化能力不足看似Markdown的语法相当结构化，但实际上Markdown的结构并不是强绑定。以JSON作为对比。例如，我们可以使用JSON扩展https://json-schema.org/结构。这种结构甚至可以反转一个完整的表单应用程序。原因是可以为每个Key和level定义JSON。首先是结构，其次是内容。而Markdown正好相反，先有内容，后有结构。例如，我们可以在Markdown的任何地方写任何HTML标签，或者任何段落的问题。这些内容无法序列化。即使我们按照浏览器解析HTML的规则将它们解析成JSON，我们也无法轻易地从中提取信息。这背后的根本原因在于Markdown本身的定位是“接近UI渲染结果”。实际上，浏览器渲染UI的背后需要一套严谨的HTML语法，因为UI和背后的语法无法一一映射。一个稳定的渲染逻辑只能从源码推导到渲染，不能从渲染推导到源码。Markdown本身定位接近渲染结果，结构能力不足自然是问题。总结记得在语雀早期内测的时候，还是使用Markdown进行编辑，但是Markdown编辑入口很快就被去掉了。这件事也引起了很多开发者的不满，甚至开发了一些Markdown编辑器Plugins，一度大受欢迎。但渐渐地我们都习惯了所见即所得的编辑方式。Markdown给人留下的唯一印象就是快捷键。街区越走越远。如果当年技术被Markdown锁定，就不可能有今天这么高级的编辑体验。因此，技术前瞻性真的很重要。程序员都爱Markdown，但是提前看到它在互联网发展现阶段的局限性，设计一套结构化数据来替代Markdown结构，并不是每个人都能想到的。我们需要从动态的角度看待技术，我们也必须放下技术人的偏见，让位于产品定位。讨论地址为：Jingdu《对 Markdown 的思考》·Issue#397·dt-fe/weekly想参与讨论的请点这里，每周都有新话题，周末或周一发布。前端精读——帮你过滤靠谱的内容。关注前端精读微信公众号版权声明：免费转载-非商业-非衍生保留属性（CreativeCommons3.0License）