打开任意一个 GitHub 仓库，你首先看到的不是代码，而是 README.md。这个文件通常用 Markdown 写成，也是项目里被阅读次数最多的文档。招聘启事、学术论文和法律合同很少放在 Markdown 里，但 Web 上大量技术写作都依赖它。要理解原因，得回到一种在渲染之前就为了便于阅读而设计的格式。
Markdown 从何而来
2004 年，技术作家 John Gruber 在 Aaron Swartz 的参与下发布了 Markdown 语法规范。Gruber 的目标很实际：他需要一种在纯文本下好看、随后又能转成 HTML 的写作方式。当时的 Web 靠标签驱动，写博客意味着给每个段落、列表和链接都包上尖括号。对大多数人发布的文字而言，Gruber 认为这种噪音没有必要。
结果是一套很小的约定：
- 标题用
#符号。 - 列表用
-或*。 - 链接用
[text](url)。 - 强调用
*text*或_text_。 - 代码用反引号。
这些约定借用了邮件、Usenet 以及作者们已经熟悉的纯文本习惯。Markdown 没发明多少新东西，只是把它们写成了规则。
Gruber 还发布了一份参考实现 Markdown.pl，一个把语法转成 HTML 的 Perl 脚本。可读的源格式加上确定的输出格式，让它很容易被接受。作者得到的是可以在任何文本编辑器里修改的文件；发布者得到的是可以用 CSS 设置样式的干净 HTML。
Markdown 不是 HTML
这话听起来显而易见，但技术上的区别很重要。HTML 是一种结构化文档格式，描述元素、属性、嵌套和行为。浏览器并不关心源码对人类是否好看，它只关心能从标记构建出的 DOM。
Markdown 是一种写作约定。它没有 DOM，没有事件处理器，没有表单，除了用户在 frontmatter 里添加的内容之外也没有元数据 schema。与其说它是一种标记语言，不如说它是一种速记。把 Markdown 送进解析器，输出通常是 HTML，但 Markdown 本身只关注作者手打的文档部分：标题、段落、强调、列表、链接、图片和代码。
这种差异决定了它们各自的位置：
| 任务 | Markdown | HTML |
|---|---|---|
| 写初稿 | 在任何编辑器里都快速可读 | 冗长，打断思路 |
| 版本控制 diff | 干净，按句级改动 | 因标签而嘈杂 |
| 精确布局 | 设计上较弱 | 强 |
| 交互 | 无 | 原生 |
| 样式 | 交给渲染器 | 内联或 CSS |
HTML 是最终页面，Markdown 是手稿。
为何传播得这么快
三股力量把 Markdown 从一个小众 Perl 脚本推成了技术写作的默认语言。
版本控制。 Git 成为标准后，开发者开始把文档和代码放在一起管理。纯文本胜出，因为 diff 可读。HTML 和 Word 文档会让一次小改动在 diff 里变成难以辨认的 blob；Markdown 仍然清晰。
GitHub。 2009 年，GitHub 开始在仓库页面渲染 README.md。突然间，每个项目都需要一份 Markdown 文件。Stack Overflow 也在问答中采用 Markdown。开发者每天使用的平台要求它，于是他们学会了这套语法。
静态网站生成器。 Jekyll、Hugo、Gatsby，以及后来的 Next.js 等工具把 Markdown 文件变成了完整网站。作者无需 CMS 就能发布。源文件放在 Git 仓库里，构建步骤生成 HTML。这种工作流现在被称为 docs-as-code，它让 Markdown 成为现代 Web 很大一部分内容的输入格式。
笔记应用完成了最后一推。Obsidian、Notion、Bear、Logseq 和 iA Writer 都支持 Markdown 或其近亲。这种格式走出了开发者工具，成为整理个人知识的一种方式。
Markdown 会取代 docx 和 PDF 吗？
不会。这个问题之所以出现，是因为 Markdown 看起来轻量，而其他格式显得笨重，但它们解决的是不同问题。
.docx 是一个压缩的 XML 包，为富文本编辑而生：修订追踪、批注、样式、目录、邮件合并和嵌入媒体。合同、报告以及需要非技术用户来回编辑的文稿都用它。
PDF 是一种固定版式的电子纸张格式，能在不同设备上保持字体、间距和分页一致。发票、简历或需要在任何设备上看起来一模一样的学术论文，正好需要这些特性。
Markdown 是一种交换格式。它适合起草、版本管理和发布到 Web；却不擅长页面布局、精确排版和印刷级输出。实际的流程是：用 Markdown 写作，当文档需要离开文本编辑器时再转成 docx 或 PDF。
这也是浏览器端转换器派上用场的地方。当 Markdown 草稿需要变成可分享的 PDF 时，我们的 Markdown 转 PDF 转换器 在本地完成转换。如果你从 PDF 出发，想要可编辑的 Markdown，PDF 转 Markdown 转换器 会在不上传文件的情况下提取结构。
Markdown 的优点与短板
优点
- 源码可读。 Markdown 文件几乎和渲染后的页面一样干净。你可以在终端、邮件客户端或手机备忘录里直接阅读。
- 可移植。 它是纯文本，没有专有厂商、没有许可证、也不会因二进制格式损坏。
- 对 diff 友好。 Git 能准确显示是哪句话改了，作者和审阅者立刻受益。
- 工具丰富。 每种编程语言都有解析器，每个主流平台都有编辑器。
- 原生面向 Web。 它能编译成 HTML，而 HTML 正是 Web 的实际输出格式。
局限
- 规范有歧义。 Gruber 的原始规范对边界情况未作定义，不同解析器对同一输入可能生成不同 HTML。这正是 CommonMark 出现的原因，但并非所有工具都遵循它。
- 无法控制版式。 如果不回到 HTML 或 CSS，你无法定位图片、设置页边距或定义打印样式。
- 方言混乱。 GitHub Flavored Markdown、Pandoc Markdown、MultiMarkdown、Obsidian Markdown 和 MDX 都增加了互不兼容的扩展。为一个工具写的文件，到另一个工具里可能渲染出错。
- 表格和脚注是事后补充。 它们由扩展支持，而非核心语法，行为也各不相同。
客观地说，Markdown 擅长 90% 的写作场景：段落、列表、链接和代码。剩下的 10% 被它推给 HTML 或专门格式。
AI 时代的 Markdown
如果你用过大型语言模型（LLM），你一定见过 Markdown。大多数聊天界面默认把 LLM 输出渲染成 Markdown。这有实际原因。
首先，Markdown 紧凑。Token 成本很高，用 # 代替 <h1></h1> 能省空间。其次，Markdown 结构简单。标题、列表和代码块对模型来说容易生成，对解析器来说也容易校验。第三，训练数据里满是 Markdown。GitHub、Stack Overflow、Reddit 和文档站点都在用它，模型能可靠地学会这套语法。
除了聊天输出，Markdown 还成了 AI 知识系统的存储格式。检索增强生成（RAG）流水线经常把文档切分成 Markdown 或纯文本，因为结构可预测。向量数据库、笔记工具和编程助手把长期上下文存成 Markdown 文件，因为人类能读、机器能解析。
风险在于方言不一致。一个模型输出 GitHub 风格表格，另一个可能对同一张表使用 HTML。混合方言的知识库在工具之间迁移时会出问题。要让 AI 生成的 Markdown 保持可移植，唯一办法是统一使用 CommonMark 或有文档记录的方言。
Markdown 的未来与演进
Markdown 不会变成更复杂的格式。每一次试图让它更丰富的尝试——表格、脚注、定义列表、属性——都在削弱让它流行起来的简洁性。真正的演进发生在两个方向。
标准化。 2014 年启动的 CommonMark 定义了严格的解析规范。越来越多工具实现了它，文件从一个解析器换到另一个时出现的意外因此减少。
嵌入。 MDX 允许作者在 Markdown 里导入 React 组件。Jupyter Notebook 把 Markdown 单元格和可执行代码混合在一起。静态网站生成器把 Markdown 当作结构化内容的数据源。在这些场景里，Markdown 保持小巧，周围的工具提供能力。
未来很可能还是老样子：Markdown 作为通用的纯文本草稿格式，再由转换器把它变成 HTML、PDF、docx、幻灯片或任何目标需要的格式。
按平台分类的阅读与编辑工具
使用 Markdown 不需要专门的 App，任何文本编辑器都可以。不过有些工具能让体验明显更好。
Windows
- VS Code 配合 Markdown 扩展：开发者的默认选择，支持预览、lint 和 Markdown-it 渲染。
- Typora：极简的所见即所得编辑器，在你需要之前隐藏语法。
- MarkText：Typora 的开源替代品，提供干净的分栏视图。
- Notepad++：适合快速编辑，通过插件支持 Markdown 语法高亮。
macOS
- iA Writer：专注无干扰写作和语法控制。
- Bear：使用类 Markdown 语法的笔记应用，用于个人知识管理。
- Ulysses：受长篇写作者欢迎，适合发布到 Web。
- Marked 2：不是编辑器，而是为在其他地方编辑的文件提供强大的实时预览渲染。
Linux
- Ghostwriter：支持实时预览的无干扰 Markdown 编辑器。
- Apostrophe：简洁的 GTK 编辑器，专为散文写作设计。
- ReText：简单编辑器，可导出为多种格式。
- Vim / Neovim / Emacs：对已经习惯终端的写作者来说无可替代。
跨平台
- Obsidian：本地优先的知识库，支持链接、图谱和插件。
- Logseq：大纲工具，把所有内容存为 Markdown 或 Org 文件。
- Joplin：开源笔记应用，支持端到端加密和 Markdown。
按语言分类的 Markdown 库
如果你在构建解析或渲染 Markdown 的软件，很少需要自己写解析器。生态已经很成熟。
| 语言 | 库 | 说明 |
|---|---|---|
| Python | markdown, mistletoe, markdown-it-py | markdown 是经典实现；markdown-it-py 是符合 CommonMark 的移植版 |
| JavaScript / TypeScript | marked, markdown-it, remark / unified | remark 属于 unified 生态，用于基于 AST 的处理 |
| Go | goldmark, blackfriday | goldmark 符合 CommonMark 且可扩展 |
| Rust | pulldown-cmark, comrak | 快速、安全、聚焦 CommonMark |
| Ruby | redcarpet, kramdown | redcarpet 是 GitHub 风格；kramdown 是 Jekyll 默认 |
| Java | commonmark-java, flexmark-java | flexmark 支持许多 Pandoc 风格扩展 |
| C# | Markdig | 高度可扩展，被 Statiq 等静态网站生成器使用 |
这些库大多都能很好地处理核心语法。差异体现在扩展、性能以及对 CommonMark 的严格程度上。选择时要根据你需要支持的方言，而不仅仅是你使用的语言。
结论
Markdown 胜出不是因为它强大，而是因为它不碍事。作者可以打开任意文本编辑器，敲完文档，然后把它提交到版本控制，根本不用考虑文件格式。这种取舍是故意的：Markdown 放弃版式精度，换取可移植性和可读性。
这种取舍让它支撑着 README、文档、静态网站、笔记应用，以及如今的 AI 输出。它也会继续与 docx 和 PDF 共存。每种格式都有自己的任务，Markdown 的任务是成为纯文本起点。当你需要把这个起点搬进更丰富的格式时，转换器通常是下一步。
