Markdown 是一种轻量级标记语言,使用纯文本编辑器即可编写带格式的文本。它由 John Gruber 与 Aaron Swartz 于 2004 年共同创建,设计目标是让文档"易读、易写",且作为纯文本即可直接发布,无需看起来像被标签或排版指令标记过。Markdown 源文件中的标记符号会被解析程序转换为 HTML,因而广泛用于技术文档、代码仓库 README、博客写作与笔记应用。由于缺乏早期统一规范,社区衍生出多种方言,其中 CommonMark 与 GitHub Flavored Markdown(GFM)已成为事实上的主流规范。
# 标题 会被转换为 <h1>标题</h1>,无序列表项会被转换为 <ul><li>…</li></ul>,最终输出可在浏览器中渲染的 HTML 文档使用 1~6 个 # 表示六级标题(ATX 风格),# 之后需加一个空格或制表符;标题为空时可省略分隔空格
粗体用 ** 或 __ 包裹文本,斜体用 * 或 _ 包裹文本
无序列表使用 -、+ 或 * 加空格开头;有序列表使用数字编号加英文句点与空格开头
行内链接格式为 [文本](地址),图片在链接语法前加 !:
行内代码用反引号 ` 包裹;代码块可用 4 个空格缩进或围栏代码块(三个反引号)表示
引用块以 > 开头;分隔线由 3 个及以上 *、- 或 _ 组成
段落之间用空行分隔;行尾加两个空格或反斜杠可实现硬换行
以 -、+ 或 * 开头,后接空格与列表内容,三种符号语义等价
以数字编号加英文句点与空格开头(如 1. ),实际显示顺序由首个编号决定,后续编号会自动递增
子列表需相对父项内容列进一步缩进(通常 2 或 4 个空格),从而形成层级结构
GFM 支持 - [ ] 表示未完成、- [x] 表示已完成,常用于 Issue 跟踪与待办清单
基本形式为 [链接文字](链接地址),可在地址后加空格与引号书写提示标题
先在文中用 [标签][id] 引用,再在别处统一定义 [id]: 地址,便于在同一文档中多处复用
用尖括号包裹 URL 或邮箱地址(如 <https://example.com>)即可自动转换为超链接
语法为 ,替代文字在图片无法正常显示时呈现,地址可为本地路径或网络地址
将代码行缩进 4 个空格或 1 个制表符即可,适用于简短代码;但直观性较弱,且不支持语法高亮
用 3 个及以上反引号 ``` 或波浪号 ~~~ 包裹代码,并可在开头指定语言名称以实现语法高亮
用一对反引号包裹代码片段(如 `code`),用于在正文中嵌入变量名、命令或短代码
在段落每行开头加 >(后接可选空格),即可将内容标记为引用块
多行引用可在每行前加 >,也可在后续行使用"惰性续写";引用块内部可再嵌套一层 > 引用
引用块内部仍可嵌套标题、列表、代码等其它 Markdown 语法,保持结构完整
GFM 支持表格:首行为表头,第二行为分隔行(由 --- 定义列对齐),之后为数据行,单元格以 | 分隔
分隔行中用 :--- 表示左对齐、---: 表示右对齐、:---: 表示居中,默认左对齐
表格属于 GFM 扩展语法,并非所有解析器都支持;块级元素(如代码块、引用块)不能嵌入单元格内部
是基于 CommonMark 的严格超集,新增表格、删除线、任务列表、自动链接等扩展;GitHub 于 2017 年 3 月发布正式规范,并开源了基于 cmark 的 C 语言参考实现
早期扩展之一,新增围栏代码块、表格、脚注、定义列表等能力,最初以 PHP 实现
在基础语法上扩充,支持更多输出格式与文档元素,便于撰写长篇结构化文档
由文档转换工具 Pandoc 支持,扩展了脚注、引文、数学公式等学术写作功能
还有 R Markdown、Kramdown 等多种派生,分别服务于数据科学、静态网站等不同场景
由 John MacFarlane 开发的多格式文档转换工具,内置强大的 Markdown 解析能力,采用"读取为抽象语法树(AST)再写入目标格式"的架构
JavaScript 生态有 marked、markdown-it 等;Python 生态有 Python-Markdown、mistune 等,不同语言均有成熟实现
GitHub、GitLab、Reddit 等平台均内置各自的 Markdown 解析器,多数基于或兼容 CommonMark 与 GFM
Typora 将源码编辑与渲染预览合二为一,实现所见即所得,并支持 GFM 以及数学公式、流程图等扩展
VS Code 等代码编辑器原生支持 Markdown 语法高亮与预览,是技术写作的常用工具
Obsidian、Bear、Logseq 等以纯 Markdown 文件作为原生存储格式,强调文档的可移植性与持久性
众多写作平台与文档工具内置 Markdown 支持,便于团队协同编辑与内容沉淀
最常见的输出为 HTML;借助转换工具还可生成 PDF、EPUB 等电子文档格式
可转换为 Word(DOCX)、OpenDocument(ODT)、RTF、LaTeX 等,满足正式排版与出版需求
借助 Pandoc 等工具,Markdown 还能转换为 LaTeX Beamer、PowerPoint、reStructuredText 等十数种格式
Pandoc 是代表性的"瑞士军刀"式转换器,支持在 Markdown(含 CommonMark 与 GFM)与数十种格式之间相互转换
Jekyll、Hugo 等静态网站生成器将 Markdown 文件渲染为 HTML 页面,是博客与文档站点的常见写作格式
许多开源项目与技术文档系统以 Markdown 作为内容源,便于进行版本管理与协作维护
Markdown 易于用 Git 进行版本控制,天然适配代码托管平台的文档、Wiki 与 README 场景
尽量采用 CommonMark 规范中的通用语法,避免依赖单一平台私有的非标准扩展,减少迁移成本
通过 YAML front matter 等约定在文件头部声明标题、作者、日期等元信息,而非将其混入正文
使用 .md 或 .markdown 扩展名,并在团队内约定一致的命名规则与目录结构
仅在必要时嵌入原始 HTML,以降低在不同解析器之间的兼容风险
Markdown 的设计定位是 HTML 的轻量书写层,源文件经解析后输出为 HTML(或 XHTML)文档
Markdown 允许在文档中直接书写原始 HTML 标签,解析器会原样保留这些标签并交给浏览器处理
Markdown 覆盖了常用排版需求,但无法表达 HTML 的全部能力,复杂结构仍需借助原始 HTML 实现
Markdown 是纯文本标记语言,需记忆少量符号;Word 等采用"所见即所得"的可视化编辑方式
源文件为纯文本,体积小、便于版本控制与跨平台协作,且渲染前后都清晰可读
对复杂版式(如精细的页面排版、图文混排)支持有限,重度排版需求仍依赖 Word 等专业软件
轻量写作、技术文档、网页内容适合使用 Markdown;正式出版与精细排版则更适合传统富文本工具
Markdown 追求简洁易读,语法直观;reStructuredText(reST)更强调结构化与语义表达
reST 采用基于缩进的结构,并提供更多"角色"与"指令"机制,表达能力更强但学习成本更高
reST 是 Python 文档体系(Sphinx)的默认格式,广泛用于技术手册与 API 文档的撰写
Gruber 的原始语法说明是描述性而非规范性的,多处边界情况未明确定义,导致各实现自行判断
为补足功能,社区衍生出 GFM、MultiMarkdown、Markdown Extra 等多种方言,彼此行为并不完全一致
Markdown 没有"语法错误"的概念,解析偏差往往不会立即暴露,常在文档迁移时才被发现
CommonMark 通过明确规范与测试套件统一行为;RFC 7763 与 RFC 7764 则建立了 text/markdown 媒体类型与方言注册机制,从标准层面缓解碎片化问题