Obsidian 的 13 种内容形式，你用全了吗？

「收藏时间：2026-09-10 22:45」 【来源：https://zhuanlan.zhihu.com/p/2061921487808892976】

📄 原文内容

今天分享一下 Obsidian 的 13 种内容形式，其中有一些我自己的使用心得和踩坑经验。

01｜属性/frontmatter/YAML

一篇笔记开头两个 --- 夹住的那段内容，就是 Frontmatter，也叫属性或 YAML。

很多人刚开始会忽略它，觉得这就是填几个标签。但 Frontmatter 其实是 Obsidian 里最有架构价值的部分——它把笔记的 元数据和正文分开。正文回答「这篇笔记说了什么」，Frontmatter 回答「这篇笔记是什么」。

我每篇笔记都会写这几个字段：

---
tags:
published:
author:
link:
status:
  - 🔴未开始
---

tags 管分类，status 管状态——有了这些，配合 Dataview 插件就能在全库范围内按标签筛选、按状态归类、按时间排序。比如想看所有「进行中」的笔记，一行查询就出来了。

还有一个容易被低估的：aliases（别名）。一篇文章的文件名可能是 20260709-会议纪要，但在 Frontmatter 里写 aliases: [上周产品复盘]，之后在任何笔记里打 [[上周 都能补全跳转过来。这个比在正文里写别名好用，因为它是全局索引层面的。

需要注意：Frontmatter 不是标准 Markdown。如果要迁移到其他工具，数据本身不会丢（YAML 仍然是纯文本），但其他工具不能像 Obsidian 那样基于它做查询和分类。这个取舍我觉得值。

02｜文本格式

- 粗体（ **内容** ）
- 斜体（ *内容* ，_内容_ ）
- 粗斜体（ **_内容_** ）
- 删除线（ ~~内容~~ ）
- 高亮（ ==内容== ）

我一般只用粗体、斜体、高亮，粗斜体、删除线用的比较少，主要考虑样式多了，转成word和其他格式，避免转化时的异常，所以文本格式用的比较少。

我在 Obsidian 中通过主题 CSS 给三类文本格式分配了颜色——粗体显示红色、斜体显示绿色、高亮显示橙色，分别对应不同的场景：

03｜列表

• 无序列表
• 有序列表
• 任务列表

很多人觉得列表就是列表，没啥好说的。但三种列表对应三种完全不同的思维结构。

无序列表是「分类」——苹果、香蕉、牛奶，它们是一个集合，不分先后。

有序列表是「顺序」——先下载、再安装、再配置，步骤不能乱。

任务列表是「状态」——每条都有一个「已完成/未完成」，本质上是轻量级的项目管理。

我的习惯是：有序列表我其实用得不多。需要强调顺序时我直接在内容里写清楚，结构更干净。无序列表的灵活性更高，写起来不用操心序号对齐的问题。

还有一个很多人不知道的用法：任务列表配合 Tasks 插件或 Dataview，可以跨文件聚合所有未完成的任务。比如我在不同笔记里分别写：

- [ ] 读完《认知觉醒》 #读书
- [ ] 整理 inbox #admin

然后一个查询就能看到全部待办。任务列表的真正价值在于在全库范围变成「可查询的待办信号」。

类型	本质	我用得多吗
无序列表	分类 / 集合	每天都用、频率最高
任务列表	状态 / 待办	项目笔记必用，配合 Dataview 真香
有序列表	顺序 / 步骤	相对任务列表少一些

04｜引用

• 引用块 >
• 标注块 Callout

引用块就是 >，标准 Markdown 语法，到处都能用。

Callout 是 Obsidian 的扩展语法，我一般不建议用。

Callout 最大的问题是会把你锁在 Obsidian 上。你用 [!tip] 写了一条技巧，哪天切到 Typora、VS Code 或者其他笔记软件，这些内容不会自动变成普通引用块，可能会直接显示出源码符号，阅读体验很差。

我的习惯是引用坚持用标准 >：

• 导出到 PDF / HTML 完全正常
• 粘贴到微信公众号、知乎都能被正确识别
• 迁移到任何工具都不会出问题

Callout 的彩色框和图标确实好看，但你得接受一个前提：你确定一辈子只用 Obsidian。如果不是，标准 > 是更安全的选择。

05｜代码

• 行内代码 `code`
• 代码块 ```

行内代码我用来标「名词」，代码块我用来标「片段」。区别很多人没想过——行内代码是给读者扫一眼的，代码块是给读者仔细看的。

用 fetch() 方法发送请求。 → 行内代码，读者知道这是一个方法名，不需要单独一行。

def hello(): print("Hello, world!") ``` → 代码块，需要独立展示，有格式有缩进。

一个经常被忽略的点：代码块的语言标注。很多人写完 ``` 就不写语言名了，但 Obsidian 依赖这个做语法高亮。

不写语言名，整段代码灰蒙蒙一片，关键字没有颜色，跟普通文本没区别：

def hello():
    print("Hello")

写上 ```python，关键字自动着色，字符串高亮，结构一目了然：

def hello():
    print("Hello")

阅读体验完全是两回事。

还有一个很多人不知道的写法：如果要在文章里展示代码块本身（而不是展示代码的运行结果），需要用四组反引号包裹：

````markdown
```python
def hello():
    print("Hello")

````

这样渲染出来，读者看到的就是完整的 Markdown 代码块语法，而不会真的被当作代码块执行。写 Obsidian 教程类文章时这个技巧特别常用。

## 06｜数学公式

-   行内数学 `$...$`
-   数学块 `$$...$$`

Obsidian 用 Katex 渲染数学公式，也支持 MathJax，在设置里可以切换。

有一个容易踩的坑：行内数学用 `$...$`，如果正文里本来就有 `$` 符号，会误触发渲染。解决方案：在 `$` 前加反斜杠 `\$` 转义，或者在 `$` 后面加个空格隔开。

我的使用习惯：行内数学尽量少用，只有公式极短且不会跟文本混淆时才用。稍微复杂一点的公式一律用公式块——渲染稳定、不会误触、支持 `\tag{}` 加编号，写论文式笔记时很好用。

## 07｜表格

GFM（GitHub Flavored Markdown）标准表格，支持对齐符号。

坦白讲，Obsidian 里写表格体验一般——没有图形化编辑，对齐靠手敲空格。但我还是经常用，因为表格有一种别的形式替代不了的信息结构：对比。

| 特性 | Obsidian | Notion |
| --- | --- | --- |
| 离线 | ✅ | ❌ |
| 本地存储 | ✅ | ❌ |
| 插件生态 | ✅ | ❌ |

这种并排对比，只有表格最直观。

几个小技巧：

1.  `:---` 左对齐、`:---:` 居中、`---:` 右对齐写了对齐符号，阅读模式真的生效。
2.  超过 5 列的表格我建议用 Base（多维表格）代替。Markdown 表格太宽了，手机上直接裂开。
3.  通过 `
列名
` 可以控制列宽（仅部分渲染器支持），适合需要固定宽度的列。

## 08｜链接

-   普通链接 ``
-   Markdown 链接 `[描述](url)`
-   Obsidian 内链 `笔记名`
-   别名 `显示名`
-   块链接 `笔记^块id`
-   嵌入 ``
-   标题嵌入 ``

链接是 Obsidian 最核心的能力，但 80% 的人只用了最基础的 `笔记名`。

我按实用程度排个序：

| 语法 | 用途 | 实用度 |
| --- | --- | --- |
| \[\[笔记名\\|显示名\]\] | 内链 + 自定义显示名 | ⭐⭐⭐ 每天用，必学 |
| \[\[笔记名\]\] | 基础内链 | ⭐⭐⭐ 每天都在用 |
| !\[\[笔记名\]\] | 嵌入整个笔记 | ⭐⭐ 拼装 MOC 时用 |
| !\[\[笔记名^块id\]\] | 精确嵌入某一段 | ⭐⭐ 引文卡片专用 |
| !\[\[笔记名#标题\]\] | 嵌入某标题下的内容 | ⭐⭐ 聚合同类笔记时用 |
| \[描述\](url) | 外链 | ⭐ 偶尔用 |
|  | 原始 URL | ⭐ 几乎不用 |

关于 `笔记名` 和 `[描述](url)` 怎么选，我绕了不少弯路。

最早我一直用 Obsidian 内链 `笔记名`，后来想把笔记迁移到其他软件也能正常打开链接——毕竟外部软件不认识 `笔记名`。于是我把所有内链改成了标准 Markdown 链接 `[描述](url)`。

结果踩了一个大坑：文件名或文件路径一改，Markdown 链接全断。因为 Markdown 链接是硬编码路径的，文件移动后路径对不上，链接就废了。

这时候我才真正理解 `笔记名` 的优势：它是全局索引的。不管你文件移到哪个文件夹、改成什么名字，只要在 Obsidian 内部操作重命名和移动，所有引用这个笔记的 `笔记名` 都会自动更新。

但注意一个关键前提：**必须要在 Obsidian 内部修改文件名和路径**。如果在外部（比如 Finder 或终端）改了文件名或移动了文件，Obsidian 的全局索引不会触发更新，链接一样会断。这是新手最容易被忽视的地方。

最有价值但最容易被忽略的是别名。笔记文件名可能是「20260709-会议纪要」，但你不想正文里显示这么一串。写 `上周的复盘会议`，链接指向正确文件，显示出来是整洁的中文文本。

块引用更厉害。在任意一行后面写 `^abc` 作为锚点，另一篇笔记里写 ``，只嵌入那一行。我做「引文卡片」时必用这个——永久笔记里只保留自己消化的内容，原文精确引用到原文笔记。

还有一点：嵌入 `` 和内链 ` ` 的本质区别。内链是一个跳转入口，告诉读者「这里有篇相关笔记你自己点进去看」。嵌入是直接把内容拉过来实时渲染，告诉读者「这篇的相关内容已经放在这里了」。我一般在 MOC 里用嵌入聚合多篇笔记的开头几段，形成目录式概览。

不过用 `` 和 `` 需要注意风险：这两种引用锚点都是脆弱的。如果源文件的标题改名了、块删掉了、或者内容被移动了位置，嵌入就会断掉，显示成空白或解析失败。`^块id` 尤其容易断，因为块 id 是 Obsidian 自动生成的，一旦重新编辑过那个段落，块 id 就可能变掉。`#标题` 稍微稳一点——标题改名后更新一下引用就行，但如果整个标题被删了，引用照样失效。所以嵌入适合引用稳定不常改的内容，频繁修改的笔记用内链 ` ` 更安全。

## 09｜图片

-   Markdown 方式 ``
-   Obsidian 方式 ``

两种方式语法差不多，但在文件管理层面有本质区别。

Markdown 方式：路径是相对路径，换到其他编辑器也通用。但笔记一移动，路径大概率断掉。

Obsidian 方式：图片统一存到附件目录，用 `` 引用。不管笔记移到哪个文件夹，路径不会断。

我一开始用 Markdown 方式，后来全部换成 Obsidian 的了——因为 Obsidian 的 `` 是全局索引，不受文件位置影响。

还有一个技巧：控制图片显示宽度。`` 显示 400px 宽，`` 控制高度。现在 Obsidian 也支持直接拖拽图片边缘手动缩放，会自动生成尺寸参数。不过我写笔记时还是习惯带 `|600`，手动控制更准确一些。

## 10｜脚注

脚注被严重低估了。很多人写补充信息喜欢用括号，一句话被切得七零八落：

> 机器学习（特别是深度学习，虽然严格来说深度学习是机器学习的一个子集）在过去十年发展迅速。  

脚注的写法是：

> 机器学习[\[1\]](https://zhuanlan.zhihu.com/write#fn-1)在过去十年发展迅速。  

正文保持流畅，补充信息放到页尾。Obsidian 导出 PDF 时脚注自动变成标准的页脚格式，体验很好。

而且在 Obsidian 中还有两个很实用的脚注功能：一个是「脚注悬浮预览」——鼠标悬停在 `[^1]` 上就能看到脚注内容；另一个是「脚注视图」——点击脚注标记右侧边栏会显示所有脚注列表，方便快速浏览和跳转。

我的原则：一句话说不完的补充、来源出处、延伸阅读，全部扔脚注。正文只留主线。

## 11｜注释

-   HTML 注释 ``
-   Obsidian 注释 `%% %%`

很多人不知道这两个有什么区别。关键区别在于：`%%` 是 Obsidian 独有语法，在阅读模式和导出到 PDF 时都不会显示。HTML 注释 `` 是标准语法，在源码中会被保留，但在渲染输出中同样不会显示。

所以我用 `%%` 来写：

-   待补充的提示——「」
-   写作思路——「」
-   个人备注——「」

`` 我几乎不用。唯一场景是把 Obsidian 笔记发布到博客平台时，希望给渲染引擎留一些注释指令。

踩过的坑：切到 VS Code 或 Typora 时，`%%` 内容会直接暴露。如果你需要在多个工具间切换，建议统一用 HTML 注释。

## 12｜Mermaid

Mermaid 是 Obsidian 原生支持的图表引擎，语法类似代码块，语言标注写 `mermaid`。

但说实话——实际体验没有想象中那么好。中文经常乱码，复杂流程图布局不可控，节点一多就挤成一团。我一度放弃过它。

后来我总结了三条适用场景：

1.  **简单流程图**（不超过 5 个节点）—— 文字改起来方便
2.  **时序图**—— Mermaid 的时序图做得最好，展示消息顺序很直观
3.  **需要嵌入 Markdown 导出**—— 如果用 Excalidraw 画图，导出 HTML/PDF 时不包含在内，Mermaid 是文本格式跟着走

复杂一点的图，我老老实实改用 Excalidraw 画完截图粘贴。虽然改文字不能自动重排，但至少布局可控、可读性强。







## 13｜HTML

Markdown 里可以直接写 HTML。理论上 `
`、``、`