Markdown 的诞生背景
2004 年以前，互联网上写博客意味着要手动敲 HTML 标签。写一篇普通博文，作者需要把 <p>、<strong>、<ul><li> 等反复输入，排版工作占用了大量精力，严重干扰写作本身的专注度。
2004 年，John Gruber（Daring Fireball 博主）和 Aaron Swartz（RSS 规范联合作者、Reddit 联合创始人）合作创造了 Markdown。他们的核心目标只有一个：让写作者用最接近自然语言的纯文本写出排版优美的 HTML，同时确保原始文本本身就有良好的可读性。
Markdown 的工作原理
Markdown 的工作流程非常简单：你用文本编辑器写 .md 文件，然后 Markdown 解析器（Parser）读取这个文件，将其中的 Markdown 语法转换为 HTML 结构。
以一个简单示例为例，理解转换过程：
# 你好，世界
这是一段**加粗**文字和
*斜体*文字。
- 第一点
- 第二点
<h1>你好，世界</h1> <p>这是一段<strong>加粗</strong> 文字和<em>斜体</em>文字。</p> <ul> <li>第一点</li> <li>第二点</li> </ul>
最终渲染效果：
你好，世界
这是一段加粗文字和斜体文字。
- 第一点
- 第二点
核心设计哲学
Gruber 在设计 Markdown 时，明确提出了以下设计原则，这些原则至今仍影响着所有基于 Markdown 的工具的设计决策：
1. 可读性优先（Readability Above All Else）
这是 Markdown 最重要的设计原则。原始的 Markdown 文本即使不经过渲染，也应该是清晰可读的。Gruber 的原话是："A Markdown-formatted document should be publishable as-is, as plain text, without looking like it's been marked up with tags or formatting instructions."
对比一下 HTML 和 Markdown 对同一内容的书写方式：
<h2>安装步骤</h2> <ol> <li>下载安装包</li> <li>运行 <code>./install.sh</code></li> <li>配置环境变量</li> </ol>
## 安装步骤
1. 下载安装包
2. 运行 `./install.sh`
3. 配置环境变量
2. 借鉴电子邮件惯例（Email-Inspired Conventions）
Markdown 的许多语法来自于程序员多年来在纯文本邮件中形成的自然排版习惯：
| 惯例来源 | Markdown 语法 | 含义 |
|---|---|---|
| 邮件引用用 > 前缀 | > 引用文字 | 引用块 |
| *单词* 表示强调 | *斜体* | 斜体 |
| _单词_ 表示下划线强调 | **加粗** | 加粗 |
| 列表用 - 或数字开头 | - 项目 | 无序列表 |
| 标题用 === 下划线 | # 标题 | 标题 |
3. 最小化语法（Minimal Syntax）
Markdown 故意保持语法简单，学习成本控制在 30 分钟以内。它不试图替代 HTML，而是处理"80% 的使用场景"。对于复杂排版需求，Markdown 允许直接内嵌 HTML，这是一个务实的设计决策。
4. 专注内容，而非样式
Markdown 只描述内容的语义结构（这是标题、这是列表、这是引用），而不描述样式（字体颜色、大小、边距）。样式完全由渲染器和 CSS 决定。这与"内容与表现分离"的 Web 设计最佳实践一致。
规范的分裂与统一历程
Gruber 最初的 Markdown 规范（2004 年）只有一份简单的 Perl 实现和一篇文档说明，留有大量歧义之处。例如：
- 如果一个
#后面没有空格，是标题还是普通文字？ - 列表项缩进多少才算嵌套？
- 连续的段落文字之间需要几行空行？
不同工具（Redcarpet、Discount、Pandoc、Python-Markdown……）各自解释，导致"同样的 Markdown 在不同平台渲染结果不同"成为普遍问题。
CommonMark（2012 年 — 现在）
2012 年，Jeff Atwood（Stack Overflow 联合创始人）等人发起 CommonMark 项目，联合多位 Markdown 解析器作者，历经 2 年，于 2014 年发布了 CommonMark 0.1 规范。该规范的特点：
- 精确无歧义：每一个语法规则都有明确的优先级和边界情况说明
- 测试套件：包含 600+ 个测试用例，可验证解析器的正确性
- 多语言实现：官方提供 C、JavaScript 参考实现（cmark、commonmark.js）
GFM（GitHub Flavored Markdown）
GitHub 在 CommonMark 基础上添加了若干实用扩展，形成 GFM（GitHub Flavored Markdown）规范，于 2017 年正式发布 v0.29 规范文档：
| 分隔列的表格语法，是 GFM 最常用的扩展之一，CommonMark 不支持。- [x]/- [ ] 复选框语法，在 GitHub Issues 和 PR 中可以点击切换状态。~~删除~~ 语法，用于表示内容已废弃或被划掉。https:// 形式的 URL，无需用尖括号包裹，自动变成可点击链接。> [!NOTE]、> [!WARNING] 等语法，渲染为带颜色的提示块。主要规范对比
| 规范 | 发布时间 | 特点 | 典型使用场景 |
|---|---|---|---|
| 原始 Markdown | 2004 | Gruber 原版，有歧义 | 早期博客工具（Movable Type 等） |
| CommonMark | 2014 | 精确规范，有测试套件 | 现代解析器的基础 |
| GFM | 2017 | CommonMark + 表格/任务列表等 | GitHub/GitLab/Gitee/VS Code |
| MDX | 2018 | Markdown + JSX React 组件 | Docusaurus、Next.js 文档站 |
| Pandoc Markdown | 2006+ | 功能最丰富，含脚注/定义列表等 | 学术写作、PDF 导出 |
| MultiMarkdown | 2009 | 扩展了表格、脚注、引用等 | macOS 写作应用（Ulysses 等） |
Markdown 的应用场景
开源项目文档
- README.md — 项目门面
- CONTRIBUTING.md — 贡献指南
- CHANGELOG.md — 更新日志
- GitHub Issues / PR 描述
技术文档站
- MkDocs（Python 文档）
- Docusaurus（React 文档）
- GitBook（产品文档）
- VitePress（Vue 文档）
静态博客
- Hugo（Go 语言，速度最快）
- Jekyll（GitHub Pages 官方支持）
- Hexo（Node.js，中文社区大）
- Astro（现代 Web 框架）
数据科学 / AI
- Jupyter Notebook 文档格
- Colab 笔记说明
- Hugging Face 模型卡片
- Papers With Code 论文描述
即时通讯与协作
- Slack（部分支持）
- Discord（基础格式）
- Notion（完整支持）
- 飞书/Lark 文档
个人知识管理
- Obsidian（本地双向链接）
- Typora（所见即所得）
- Logseq（大纲式笔记）
- Bear（macOS 原生）
Markdown 解析器的工作方式
了解解析器的工作原理有助于理解一些看似奇怪的渲染行为。Markdown 解析器通常分两个阶段工作：
阶段一：块级解析（Block-level Parsing）
解析器首先将文档分割为块级元素（Block Elements）：段落、标题、代码块、列表、引用块、水平分隔线等。块级元素各自占据独立的行，不能内嵌在其他内联元素中。
阶段二：内联解析（Inline Parsing）
在每个块级元素内部，解析器再处理内联元素（Inline Elements）：粗体、斜体、内联代码、链接、图片等。内联元素可以出现在段落、标题、列表项等文本内容中。
`code`）里面使用加粗（**bold**），因为内联代码会把其中的所有字符当作字面量显示；但你可以在列表项（块级）里面使用加粗（内联）。
选择合适的编辑器
VS Code（最推荐）
微软出品的免费开源编辑器，内置 Markdown 支持，是大多数开发者的首选：
- 内置预览：
Ctrl+Shift+V（Mac:⌘⇧V）打开预览，Ctrl+K V侧边预览 - 语法高亮：内置 Markdown 语法高亮
- 扩展生态：Markdown All in One、markdownlint、Paste Image 等丰富扩展
- Git 集成：内置 Git 支持，方便管理 Markdown 文档仓库
Typora
所见即所得（WYSIWYG）Markdown 编辑器，输入语法后立即渲染：
- 无需分屏，写作体验流畅
- 支持多种主题（GitHub、学术等）
- 支持导出 PDF、HTML、Word、EPUB
- 付费软件（约 89 元人民币，一次性买断）
Obsidian
基于 Markdown 的本地知识管理工具：
- 双向链接：
[[文件名]]语法，自动建立笔记之间的关联 - 关系图谱：可视化展示笔记网络
- 500+ 社区插件，高度可定制
- 个人使用免费，同步功能收费
在线工具
| 工具 | 特点 | 适合场景 |
|---|---|---|
| GitHub 网页编辑 | 直接在浏览器编辑 .md 文件，实时预览 | 快速修改 README |
| StackEdit | 在线 Markdown 编辑器，支持 Google Drive 同步 | 临时写作 |
| HackMD | 多人实时协作 Markdown | 团队文档协作 |
| Dillinger | 简洁的在线 Markdown 编辑器 | 快速体验 |
Markdown 文件的基本结构
一个良好的 Markdown 文件通常遵循以下约定：
# 主标题 <!-- 整个文档只有一个 H1，通常是文档标题 --> 简短的介绍段落，说明本文档的目的和范围。 ## 一级章节 <!-- H2 用于主要章节 --> 章节内容... ### 子章节 <!-- H3 用于子章节，尽量避免使用 H4+ --> 子章节内容... ## 另一个一级章节 - 列表项1 - 列表项2 ## 参考资料 - [资源名称](URL) - [另一个资源](URL)
#）。从 SEO 和可访问性角度，每个页面应该只有一个 H1 作为主标题。章节应从 H2 开始，向下依次使用 H3、H4。GitHub 对此没有强制限制，但这是最佳实践。
YAML Front Matter：文档元数据
很多 Markdown 工具（Jekyll、Hugo、Docusaurus、Obsidian）支持在文件顶部用 YAML 格式描述文档元数据，称为 Front Matter：
--- title: 我的文章标题 date: 2026-03-26 author: 张三 tags: - Markdown - 写作 draft: false --- # 正文从这里开始 ...
Front Matter 用三条短横线 --- 包裹，必须位于文件最顶部。解析器会读取这些元数据并在构建时使用（如生成文章日期、作者信息等），而 Front Matter 本身不会显示在最终页面中。
Markdown 与其他轻量标记语言的对比
| 语言 | 创建时间 | 优势 | 劣势 | 主要场景 |
|---|---|---|---|---|
| Markdown | 2004 | 学习曲线最低，生态最大 | 规范分裂，功能有限 | 文档/博客/README |
| reStructuredText (reST) | 2001 | 语义更丰富，Sphinx 支持好 | 语法复杂，学习成本高 | Python 官方文档 |
| AsciiDoc | 2002 | 功能最强，支持书本级文档 | 语法繁琐 | 技术书籍（O'Reilly） |
| Org Mode | 2003 | 功能极其强大（日程/任务/代码） | 依赖 Emacs，学习门槛高 | Emacs 用户 |
| Wiki Markup | 2001 | MediaWiki 生态 | 与 Markdown 语法冲突，正在被淘汰 | Wikipedia |
Markdown 在这些语言中并不功能最强，但其简洁性和庞大生态使其成为事实标准，在开发者社区中占据绝对主导地位。
小结
- Markdown 由 John Gruber 和 Aaron Swartz 于 2004 年创建，核心目标是"可读的纯文本 + 自动转 HTML"
- 工作原理：.md 文件 → Markdown 解析器 → HTML → 浏览器/渲染器显示
- 解析分两阶段：块级解析（标题/段落/列表等）→ 内联解析（粗体/斜体/链接等）
- 规范体系：CommonMark（精确规范）是基础；GFM（GitHub 扩展）是最广泛使用的实现
- 主要用于：README、技术文档、博客、Jupyter Notebook、即时通讯等场景
- VS Code 是开发者首选编辑器；Typora 适合写作者；Obsidian 适合知识管理
- YAML Front Matter 为文档提供元数据，广泛用于静态站点生成器