---
title: "File-first：文件即事实来源"
description: "笔记就是磁盘上的纯 Markdown 文件：它们是事实来源，而索引、图谱与搜索都是可重建的派生产物。"
---

# File-first：文件即事实来源

Notarium 的数据单元，是磁盘上的一个纯 Markdown 文件。不是别人数据库里的一行记录，也不是专有存储里的一个块，而是一个能用任意编辑器打开的文件——即便离开 Notarium，它依然完整可读。这就是 file-first 原则，其余一切都由此而来。

## 什么是“事实”，什么是派生

事实来源就是这些 `.md` 文件本身。凡是能从其内容计算得出的，都属于派生产物，都可以重建：

- **派生产物**（通过重新扫描从零重建）：搜索索引、`[[wikilinks]]` 图谱、目录树、片段。删掉索引也不必担心——引擎会在下次启动时重新为文件建立索引；
- **不可派生**（存放在独立的元数据库中）：版本历史、用户、成员资格与访问权限。这些无法从文件文本中重建，因此被统一挪进一个明确独立出来的归宿。

身份则恰恰相反，它锚定在文件本身之中：笔记的 `notarium-id` 存于其 frontmatter，空间与项目的标识符存于标记文件（`.notariummeta`）。正因如此，元数据库中的空间表与项目表只是一份可经扫描重建的缓存，而非身份的唯一归宿：即便把文件夹搬到 Notarium 之外，身份依然存续。

> [!note] 为何重要
> 丢失索引无关紧要：重建一次即可。重建过程中，文件本身不会被改动——写入是原子的（先写入临时文件，再重命名），而外部编辑（git、另一个编辑器）被视为正常的工作方式，而非错误。

即便文件的大小和修改时间都原封未动，外部编辑照样会被识别——`git checkout`、同步或从归档恢复之后，正是这种情形。Notarium 不会只听信文件的元数据：最终说了算的是内容，因此各处派生视图（列表、搜索、图谱）都会向磁盘上的真实状态看齐，而不会卡在过时的版本上。

## 一篇文件笔记，而非一个块

这条边界是刻意划定的：数据单元是整篇文件笔记，而不是其中的某个段落或块。Notarium 不引入任何比文件更小的独立实体——整篇笔记始终是最小单元；而恰恰是在这一点上，基于文件的笔记应用通常会转向以数据库作为事实来源，从而失去可移植性。笔记始终是一个文件，其内部结构不过是 Markdown。

笔记按 GitHub Flavored Markdown 渲染；元数据字段则存放在文件顶部的 frontmatter 中。

## 身份经得起搬迁

每篇笔记都有一个稳定的内部标识符 `notarium-id`——文件 frontmatter 中一个 12 字符、URL 安全的键：

```md
---
notarium-id: aB3kR7xQ_2mv
title: 我的笔记
---

笔记正文，用纯 Markdown 书写。
```

身份存在于**文件本身**，而不仅仅在数据库里。因此，重命名、在文件夹之间移动、乃至搬到 Notarium 之外，都不会让版本历史和关联沦为孤儿：日志与链接绑定的是 `notarium-id`，而非路径。文件名是派生的（经音译得到的 kebab-case，`slug(title).md`），它并不是身份。

## 不被锁定

你随时都能拷走整个文件夹一走了之——离开 Notarium，笔记依然可读、依然完整。你不需要单独的导出操作：因为你本就从未“身处其中”——你的数据始终以纯文件的形式躺在你自己的磁盘上。`git` 可以作为事实来源：为文件夹做版本管理、同步它、用你早已熟悉的工具阅读历史。

这也是 Notarium 隐私的根基：它依靠的不是端到端加密（智能服务器有意读取内容——否则便谈不上搜索、语义与智能体），而是服务器和文件都由你自己掌管这一事实。详见[空间与项目](/docs/concepts/spaces-and-projects/)和[访问模型](/docs/concepts/access-model/)。