笔记记了一千篇，然后呢
Obsidian 用户普遍的困境：笔记越记越多，但找不到、串不起来。你知道自己写过某个内容，搜索能找到，但你不知道自己在这个主题上到底积累了多少、哪些还没读、哪些项目停在半路。
问题在于纯文本笔记没有结构。Dataview 的解法是给每篇笔记加上可被查询的元数据，然后像查数据库一样查你的笔记库。
第一步：理解元数据的三种写法
Dataview 能读取的信息来自三个地方，推荐优先用第一种：
- YAML Frontmatter：笔记最顶部用三线包裹的区域，作用于整篇笔记，最规范
- 内联字段：正文中写成 字段名:: 值 的形式，适合临时补充
- 任务与列表元数据：在任务行后加标签或字段，用于任务级查询
强烈建议统一用 YAML。内联字段写起来快，但散落在正文里，后期维护是灾难。
第二步：设计一套稳定的字段
这是决定 Dataview 好不好用的关键。字段命名必须全局统一，写成 status 就全库都是 status，不要有的写 status、有的写 状态。
推荐的基础字段集：
type: 笔记类型（project / reading / meeting / idea）
status: 状态（active / paused / done）
created: 创建日期
due: 截止日期
tags: 标签
rating: 评分（1-5）
日期字段务必写成 YYYY-MM-DD 格式，Dataview 才能识别为日期类型参与比较。写成 2026年9月3日 就只是字符串，没法做时间筛选。
第三步：写第一个查询
Dataview 有三种写法，从简单到复杂：
- 内联查询：写在正文任意位置，只输出一个值。例如 `= this.status` 显示当前笔记状态
- 代码块查询：写在代码块里，输出表格、列表或任务清单，最常用
- DataviewJS：用 JavaScript 写，功能最强但复杂，非必要不用
第二个是主力。基本结构：
“`dataview
TABLE status, due
FROM #project
WHERE status != done
SORT due ASC
“`
四行分别定义了：输出什么列、从哪查、过滤条件、怎么排序。结构非常固定，掌握了这个模式就能写大部分查询。
第四步：五个高频实用场景
直接可抄的查询模板：
场景一：进行中的项目看板
“`dataview
TABLE status AS 状态, due AS 截止, rating AS 优先级
FROM #project
WHERE status = active
SORT due ASC
“`
场景二：逾期未完成的任务
“`dataview
TASK
WHERE !completed AND due < date(today) GROUP BY file.link ```
场景三：本月新增笔记
“`dataview
LIST
WHERE file.ctime >= date(today) – dur(30 days)
SORT file.ctime DESC
“`
场景四：读书笔记进度统计
“`dataview
TABLE WITHOUT ID
file.link AS 书名,
status AS 状态,
rating AS 评分
FROM #reading
SORT rating DESC
“`
场景五：统计各类型笔记数量
“`dataview
TABLE length(rows) AS 数量
GROUP BY type
“`
第五步：建立常驻仪表盘
把常用查询集中放进一篇笔记，命名为首页或仪表盘，设为启动时打开。这样每次打开 Obsidian 看到的就是全局视图，而不是某篇孤立笔记。
建议分区：进行中的项目、本周待办、最近新增、待整理（没有 type 字段的笔记）。最后一项特别有用——它能持续提醒你哪些笔记还没纳入体系。
查无类型的笔记：
“`dataview
LIST
WHERE !type
SORT file.ctime DESC
“`
第六步：配合模板固化规范
字段靠自觉维护一定失败。用 Obsidian 的模板功能：新建笔记时自动插入 YAML 模板，字段留空待填。这样保证每篇笔记都有完整骨架，Dataview 查询才不会漏掉笔记。
常见问题与误区
- 问：查询结果显示 0 条但笔记确实存在？先检查 FROM 条件是否写对，标签要带 # 号；再检查字段名拼写，大小写敏感。
- 误区：所有笔记都加几十个字段。字段越多维护成本越高，最后没人愿意填。控制在 5 到 8 个核心字段。
- 问：日期比较不生效？格式问题。必须是 YYYY-MM-DD，且 YAML 里日期建议加引号避免被解析成其他类型。
- 问：笔记多了查询变卡？限制 FROM 范围，用具体文件夹或标签代替全库扫描；避免在首页放过多复杂查询。
- 误区：用 Dataview 替代搜索。两者定位不同。搜索找具体内容，Dataview 做结构汇总。混用会两头不讨好。
效率数据与实测结论
以 800 篇笔记的知识库为例：改造前了解全局状态需要手工翻找，约 20 分钟且常遗漏；建立 Dataview 仪表盘后，打开即见全局，约 30 秒。首次梳理字段规范和批量补 YAML 约投入 3 小时。
真正的变化不是省时间，而是笔记库从仓库变成了系统。当你能看到自己的积累结构时，你就知道该往哪里继续投入，也知道哪些东西其实早该扔掉了。