为什么使用 Markdown
「写文档明明有 Word，为什么还要学 Markdown？」——这个问题几乎每个新手都会问一次。这一页要给出一个可操作的答案：不是 Markdown 更高级，而是它在「写」和「长期维护」这两件事上，把成本放在了更合适的位置。
- 专注写作：无需关心排版，语法简单。
- 跨平台：纯文本，工具/平台通用。
- 版本控制友好：可放 Git，支持 PR/Review。
- 转换方便：可导出 HTML/PDF/幻灯片。
- 可扩展：支持表格、代码高亮、公式、脚注等扩展。
这五条里真正难以替代的是「版本控制友好」。Markdown 源码是纯文本，Git 可以逐行比较两次改动，评审时能直接看到哪一句话被改过；富文本文件往往是压缩过的二进制，Git 也只会提示一句「二进制文件已变更」。对团队协作来说，评审一份 Markdown 改动和评审一份富文本改动，是两种完全不同的体验。
同一份内容，两种写法
用 Markdown 写一段安装说明，源码短到可以一眼扫完：
## 安装
- 执行 `npm install` 安装依赖
- 运行 `npm start` 启动服务渲染出来的 HTML 是这样：
<h2>安装</h2>
<ul>
<li>执行 <code>npm install</code> 安装依赖</li>
<li>运行 <code>npm start</code> 启动服务</li>
</ul>而同一段内容如果还用上行内语法写成强调加链接，渲染结果依旧由解析器补齐标签：
**注意**：请先阅读 [安装说明](https://example.com/install)。<p><strong>注意</strong>：请先阅读 <a href="https://example.com/install">安装说明</a>。</p>你写的始终是「内容是什么」，而不是「标签怎么嵌套」。真正被省下来的，正是那些与内容无关的样板：
| 写法 | 同一段内容的成本 |
|---|---|
| Markdown | 几行文字，标签由解析器补齐 |
| HTML | 每个元素都要写开始标签和结束标签，列表还要逐项闭合 |
| 富文本 | 存成二进制，Git 无法逐行比较 |
- README/技术文档/设计说明
- 博客与知识库
- 会议记录、SOP、需求文档
- 幻灯片（配合 remark/reveal.js 等）
这些场景的共同点是：内容以文字为主、需要长期保存，而且很可能在某个时刻交给另一个人或某个工具继续处理。
| 需求 | 更好的选择 |
|---|---|
| 精确控制版面、页边距与图文混排 | 排版软件或设计工具导出 |
| 多人实时协同编辑并留下评论 | 在线文档、协作文档 |
| 富交互界面、表单、动画 | 前端框架，而不是文档语法 |
| 长期存档且版式必须固定 | PDF 或固定版式的导出物 |
Markdown 的定位是「结构化纯文本」，不是「万能文档格式」。判断标准很简单：如果一份文档的价值主要在文字内容与层级结构，用 Markdown；如果价值主要在版面效果，就交给专门的排版工具。
把下面这份纯文本的项目说明改写成 Markdown，并回答：如果它放在 Git 仓库里，评审者会看到什么？
项目名：kuaiyizhi
安装：npm install
运行：npm start解题思路： 改写的要点是把「标签式」的描述变成「结构式」的写法：项目名用一级标题，安装与运行用无序列表，命令用行内代码。同时要回答评审者在 Git 里看到什么，取决于文件的存储格式是文本还是二进制。
详细步骤：
- 改写后：
# kuaiyizhi
- 安装：`npm install`
- 运行：`npm start`- 评审者看到的是逐行的文字改动：哪一行被改过、删掉了什么、增加了什么，一眼可辨。
- 如果同样的内容存成
.docx，Git 只能提示一句「二进制文件已变更」，评审者必须自己把文件下载下来对比。
最终答案： 改写如上；放进 Git 仓库后，评审者能直接看到逐行的文本差异。
读完这一页，你应当能用「可比较、可迁移、可被工具处理」这三条理由解释选择 Markdown 的动机，也能判断哪些需求应该交给别的工具。下一步可以挑一个真实项目，把项目说明从纯文本改写成 Markdown，体验一次写完即可预览的过程。