本章你会学到什么

• 理解 Markdown 的设计哲学：为什么它追求"内容优先"
• 理解为什么同一份 Markdown 在不同平台上显示效果可能不同
• 理解 Typora 在 Markdown 生态中的定位
• 建立文档结构意识：标题是骨架，不是字号
• 掌握结构元素（标题、段落、列表、引用、代码块）和行内元素（粗体、斜体、代码、链接、图片）的正确用法
• 理解图片路径管理的重要性

Markdown 的设计哲学

很多人第一次接触 Markdown 时会问：既然 Word 已经能写文章，为什么还要学一套看起来像代码的写法？这个问题很合理——如果一开始没想清楚 Markdown 到底解决了什么问题，后面的语法学习就很容易变成机械记忆。

Markdown 出现的初衷，是把写作重新拉回"内容优先"的状态。John Gruber 在最早的语法说明中强调，Markdown 的核心追求是"易读、易写"——一个 Markdown 文本即使还没被渲染，单看纯文本本身也应该足够清楚、自然。这意味着 Markdown 不是为了取代排版工具，而是为了让你在写作时尽量少被排版动作打断。

在传统富文本编辑器里，写作者经常会一边思考内容一边处理样式：字号是不是太大了，表格线是不是歪了，图片是不是应该再往左一点。Markdown 的思路相反——它鼓励你先把结构写清楚，再让软件根据结构去呈现样式。你先关心"这是一段标题""这是一条列表""这是一段引用"，然后才关心这些东西最终显示成什么样子。

也正因为如此，Markdown 特别适合知识笔记、技术文档、课程讲义和长期积累型写作。当你的材料越来越多时，你会发现真正难管理的不是"怎么把某一页排得很好看"，而是"怎么让几十篇、几百篇文档都保持清晰、稳定、可迁移"。Markdown 在这件事上非常强，因为它的底层是普通文本文件——可搜索、可版本管理、可迁移、不会被某个软件的私有格式绑住。

为什么同一份 Markdown 在不同地方显示得不一样

这是一个常见且正常的现象：同一份 .md 文件，在 Typora 里看着很好，放到 GitHub 上某些细节却不完全一样；换一个静态站点生成器后，换行、表格、脚注的表现又可能变化。

这不意味着 Markdown 本身"不稳定"。原因是 Markdown 的原始定义过于简短，很多边界情况没有被完全说死——子列表到底需要多少缩进，标题前是否必须空行，列表中的空行会不会改变结构，这些在不同实现里都曾出现过差异。CommonMark 规范的出现就是为了解决这个问题，它把这些细节写成了机器可验证的规则。

Typora 倾向于支持接近 GitHub Flavored Markdown 的常见扩展；GitHub 自己有一套面向仓库协作的渲染规则；CommonMark 则是为这些行为提供更严格的共同地基。

因此，正确的学习方式是：先掌握最稳的基础写法（标题前后留空行、井号后面加空格、列表缩进清楚、图片用相对路径），再逐渐理解平台差异。这种保守写法不仅让文档更稳定，也让源文本本身更整洁。

Typora 的定位

理论上你可以用记事本、VS Code、Vim 任何能保存纯文本的编辑器写 Markdown。但 Typora 把"源文本写作"和"所见即所得预览"结合得非常自然——你输入 # 标题，它直接渲染成标题效果，而不是左边给你看代码、右边单独给你看预览。

这并不意味着 Typora 隐藏了 Markdown。你在 Typora 中写的内容，底层仍然是标准 Markdown 源码。Typora 只是让写作过程更流畅，帮你逐步意识到：这个标题背后是 #，这个复选框背后是 - [ ]，这个表格背后是竖线和短横线。

Typora 支持的扩展包括任务列表、围栏代码块、表格、删除线、脚注、YAML Front Matter、目录和数学公式。它还提供大纲视图、字数统计、主题切换、图片管理、导出 PDF/HTML 等功能。这些能力组合在一起，使它既适合做 Markdown 学习工具，也适合做长期写作工作台。

需要提前了解的是：Typora 从 1.0 版本起不再是免费 Beta，正式使用需要购买授权。

文档结构意识

很多入门教程喜欢先列一串语法清单，但读完以后新手常常并没有真正掌握写作。原因是 Markdown 最核心的能力不是"会多少招"，而是"能不能把一篇内容写得结构分明"。最先掌握的应该是标题、段落、列表、引用和代码块——这些元素决定了文档的基本骨架。

标题：不是字号，而是层级

一级标题对应整篇文档的主题，二级标题对应主要章节，三级标题对应章节中的小节。在 Typora 的大纲面板中，标题层级会自动生成导航树——层级越清晰，大纲越有用。

# Typora 入门
## 安装与界面
### 文件树与大纲

你应该看到的是它们之间的结构关系，而不只是"大字"和"小字"。如果标题只被当成放大字体的工具，很容易出现层级混乱——比如一个三级标题前面没有二级标题，或者同一层标题承担完全不同粒度的内容。

一个兼容性习惯：井号和标题文字之间留一个空格，标题上下留空行。

段落：学会"空一行"比学会回车更重要

在 Word 里，很多人对段落的理解是"按一下回车就换行"。但在 Markdown 里，段落与换行不是同一个概念。段落是由连续文本构成的，不同段落之间靠空行分隔。

如果你只是普通换行但没有留空行，很多 Markdown 解析器会把它仍然当作同一段的一部分。Typora 会帮你更自然地处理输入动作，所以新手在 Typora 里常常意识不到这个规则的重要性。但如果你把文档放到 GitHub 或其他解析器里，规范的段落写法就会变得非常关键。

原则：如果你希望读者感受到"这里开始说另一层意思了"，那就用空行分段。段落的节奏，本质上是在安排思路的呼吸。

行内换行（不开始新段落）用 Shift + Enter。

列表：表达并列与顺序

无序列表适合表达并列项，有序列表适合表达步骤和流程：

- 安装 Typora
- 创建第一篇文档
- 学会标题和段落

1. 打开 Typora
2. 新建文档
3. 输入一级标题
4. 保存为 .md 文件

日常正文统一用 - 作为无序列表符号，最稳定也最清爽。

列表真正难的地方是嵌套。在列表中继续插入段落、引用或代码块时，需要四个空格或一个 Tab 的缩进。缩进代表层级，这件事没有真正吃透，一碰到复杂列表就会乱。

引用：借用另一层声音

引用块用 > 开头。它的真正意义是为正文引入一种"非主叙述"的声音——你可以用它放提示、定义、原文摘录、警告或补充说明。

> Markdown 的设计重点不是排版特效，而是可读性与可写性。

引用块只在"这里需要一种次级语气"时使用，而不是为了让页面看起来丰富就到处套框。

代码块：该块则块，该行内则行内

Typora 支持 GitHub Flavored Markdown 风格的围栏代码块——三个反引号开始，三个反引号结束：

```bash
mkdir notes
cd notes
```

加上语言标识（bash、python、javascript 等）可以启用语法高亮。

代码块的价值在于把"需要按原样保留的文本"从普通叙述中剥离出来——命令、配置、程序片段、JSON、YAML、日志样例都属于这种情况。如果只是在一句话里提到一个命令名或变量名，用行内代码（反引号包裹）就够了。好的文档写作不是代码块越多越专业，而是该块则块、该行内则行内。

行内语法：精确强调，不是到处涂颜色

行内语法的作用是让句子内部产生轻重、区分与提示。

粗体与斜体

粗体强调关键概念，斜体用于轻度强调、术语或语气变化。优先用星号写法，兼容性最好。

这是 **重点概念**。
这是 *轻度强调*。

粗体一旦过量，就会失去强调效果。把它理解为"给读者目光打一个聚焦点"，而不是"每一句都刷存在感"。

行内代码

行内代码用单个反引号包裹：`mkdir`、`README.md`、`Ctrl + Shift + P`。它告诉读者"这部分内容不要当普通语义理解，要当作一个需要精确识别的字符串"。在技术写作里，命令名、文件名、参数、路径用行内代码包裹，能大幅降低误读概率。

链接

行内链接的写法是 [显示文字](URL)：

[Typora 官方支持文档](https://support.typora.io/)

链接不只是"放一个网址"——它是文档建立外部连接的方式。Typora 也支持引用式链接，适合长文档中多次复用同一 URL。

图片

图片语法和链接很像，前面多一个感叹号：

![示意图](./images/example.png)

但真正重要的不是这行语法本身，而是理解 Markdown 中的图片不是"嵌入文件内部的数据"，而是"对一个图片文件的引用"。Markdown 文件本身是纯文本，图片通过路径被引用进来。

图片路径管理

很多人学 Markdown 时把注意力全放在语法上，却把图片路径当成小问题。等文档数量一多，或者换电脑、同步到 GitHub、导出到别的地方时，问题就会集中爆发：图片找不到、路径全断、配图一片红叉。

这类问题频繁出现，是因为很多人没有真正理解 Markdown 文件和资源文件之间的关系。Markdown 文档不是封闭盒子，图片、附件通常在外部文件里，通过路径被引用进来。文档写得稳不稳，不只取决于语法会不会写，还取决于文件系统是否有秩序。

一个适合长期维护的目录结构：

books/
└── typora-and-markdown/
    ├── chapters/
    │   └── 01-typora-and-markdown.md
    └── images/
        ├── chapter-01-figure-01.png
        └── chapter-01-figure-02.png

采用这种结构时，文档中的图片引用可以写成相对路径。相对路径的价值不只在于"看起来简洁"，更在于它会跟着整个目录一起移动——复制到另一台电脑、推到 GitHub、发给别人，图片都能正常显示。

建议尽早养成的习惯：

• 每个项目目录里都建立固定的图片文件夹（如 images/）
• 让 Typora 在插入图片时复制到指定目录，并使用相对路径
• 图片文件名和章节建立对应关系（如 chapter-01-figure-01.png）

GitHub 官方文档也强调：仓库内部引用文件和图片时，优先使用相对链接。绝对路径的文档只能在你自己的当前机器上正常工作。

常见误区

• 把 Markdown 当成"轻量版 Word"：Markdown 的价值在结构化表达与长期可维护性，不在像素级排版自由。如果你追求杂志级排版控制，Markdown 不是为那个目标设计的。

• 把 Typora 当成"不用学语法的编辑器"：短期看很舒服，长期会让你卡住——离开 Typora 以后你不懂源文本，不知道为什么换个平台样式不同。正确的方式是借 Typora 的所见即所得体验进入 Markdown，但最终仍然理解 Markdown 的基础规则。

• 过早追求高级功能：脚注、公式、YAML、主题 CSS、图床上传，这些在没有把标题、段落、列表、代码块和图片路径写稳之前，只会增加噪声。

• 忽略文件系统：Markdown 文档和文件名、目录、图片路径、导出位置紧密相关。如果不把 Markdown 当成"文件系统中的文档"，而只当成"编辑器里的一页纸"，迁移和发布时一定会吃苦头。

本章小结

Markdown 的核心设计哲学是"内容优先"——先写清楚结构，再让软件呈现样式。这种思路让 Markdown 特别适合需要长期维护、多次迁移的知识类写作。

同一份 Markdown 在不同平台显示可能不同，原因是历史规范对边界情况定义不够严格。CommonMark 规范正在解决这个问题。掌握保守写法（空行、空格、相对路径）能最大程度避免跨平台问题。

Typora 是一个让 Markdown 写作更流畅的编辑器——它不隐藏 Markdown，而是帮你逐步理解它。

文档写作最核心的能力是结构意识：标题是骨架（不是字号），段落靠空行分隔，列表靠缩进表达层级，引用是借用另一种声音，代码块用来隔离需要原样保留的文本。

图片路径管理是从"会写语法"到"会管理文档"的关键一步。从一开始就用固定目录、相对路径和统一命名来管理图片，能避免后期大量的路径断裂问题。

下一步

下一章会深入文档的长期维护：如何组织目录结构、管理图片与附件的路径、命名文件、以及让整个文档体系经得起时间考验。