Obsidian用久了大概都会经历这么个阶段笔记越攒越多双链连成了一张网关系图谱密密麻麻可真想找上个月读的那本书的评分或者这周还没完成的任务时却只能一篇篇点开笔记翻。自带搜索能搜关键词但搜不出状态为未读且评分高于8分的书。这时候Dataview就出现了。它把Markdown笔记当成数据库表用类似SQL的查询语法生成动态列表、表格、任务清单Obsidian瞬间从个人维基变成了个人数据中台。这篇是Obsidian 0x系列的第5篇专门聊Dataview插件。不管你是刚接触Obsidian、听说Dataview很强大但不知道怎么入门还是已经开始用基础查询、但遇到性能或语法问题这篇文章都能给到可落地的方案。我争取讲清楚它解决了什么本质问题查询语法怎么组织实战场景怎么套以及那些文档里不常提但实测很关键的性能大坑。1. 为什么是Dataview笔记一旦变多查找效率才是第一痛点1.1 笔记堆成山之后搜索和标签为什么就不够用了我见过不少朋友刚开始装Obsidian时觉得自带的Quick Switcher和全局搜索已经很爽了——毕竟能全文检索还能高亮。但用上半年、存了上千篇笔记后问题就来了搜索只能做关键词匹配做不了条件组合。举个例子你给读书笔记打了#book标签又在正文里写了状态在读。现在你想找所有2025年标记为在读且评分超过8分的书用标签和搜索就得先筛出所有#book标签的笔记再一篇篇看状态和评分。运气好可能10篇运气不好100篇纯体力活。标签系统本身也撑不住复杂查询。单个标签可以但多个标签的交集按日期范围筛选这类需求靠标签面板就撸不动了。关系图谱很有视觉冲击力但它从来不是查询工具——你能看出哪些笔记有联系却看不出哪些书还没读完。这才是Dataview存在的根本原因Obsidian存储的是Markdown纯文本天然结构化程度低当笔记数量上去缺少一层查询层来把数据从正文里提出来按条件聚合展示。Dataview补的正是这一层。1.2 Dataview在Obsidian生态里的实际定位Dataview的定位不是又一个美化笔记的插件而是一个数据查询与展示引擎。它读你的笔记文件读取每篇笔记的YAML frontmatter、行内字段、标签、文件名、创建时间等元数据然后把它们当成表格的行列通过查询语句生成新的视图。这个视图是动态的——你之后改了笔记里的字段Dataview结果会自动跟着更新大部分情况下。换句话说你不用反复维护目录页只要在库的根目录放一个Books.md用Dataview写一句列出所有状态为未读的书这个列表每次打开都会自动同步最新数据。它适合谁日记党想做月度回顾、读书党想管阅读进度、项目党想聚合任务和记录、还有喜欢做个人知识库仪表盘的朋友。它不适合谁如果你拿Obsidian纯当写作工具笔记之间不需要统计归类那用不上Dataview装了反而多一个要学的东西。1.3 元数据才是核心先把笔记结构设计好Dataview说白了是先有数据后有查询。数据从哪来主要是两处YAML frontmatter笔记开头用三个横线包起来的部分定义字段如status、author、date。行内字段Inline fields正文里写成字段:: 值Dataview也能识别。我的建议是只要是打算被Dataview查询的笔记就尽量用YAML frontmatter统一开头。这样做的好处是字段规范、不易出错而且肉眼一看就知道这篇笔记记录了哪些维度。--- type: book title: 置身事内 author: 兰小欢 status: 在读 rating: 9 started: 2026-01-10 cover: https://example.com/cover.jpg ---这就像你先给表格设计了表头Dataview才能给你生成像样的报表。如果每篇笔记字段命名三天两头变查询时就会很痛苦。本章先建立这个认知后面所有语法都建立在这套数据模型之上。2. 读懂Dataview查询语法把笔记当成数据库来提问2.1 四种查询块LIST、TABLE、TASK、CALENDARDataview的查询块是在笔记里插入一个代码块语言指定为dataview。下面这张表可以让你快速理解四种块分别适合什么场景查询类型输出形状典型场景LIST简单列表一行一条快速列出符合条件的笔记TABLE表格多列展示字段对比多个字段如书名、作者、状态TASK任务列表聚合多个笔记里的待办事项CALENDAR按日期展示的日历视图按创建时间/自定义日期展示笔记日常使用里LIST和TABLE占到了90%以上。TASK专门用于聚合任务CALENDAR则适合日记、时间日志类内容。2.2 FROM划定数据范围查询第一件事是划定范围告诉Dataview从哪里找数据。三种最常用的来源TABLE status, rating FROM Books这是按文件夹找双引号里是文件夹路径。FROM #book是按标签找FROM [[索引笔记]]是找链接到某篇笔记的内容FROM Books AND #book还能组合范围和标签。不加FROM就是全库查询例如LIST FROM #todo这里建议能限定范围就限定范围。全库扫描在笔记量几千篇的时候还感受不到问题一旦上万篇任何查询都开始变慢。这个后面讲性能时还会展开。2.3 WHERE与SORT筛选和排序的骨架WHERE是查询的灵魂它决定哪些笔记进入结果。语法上支持常见的比较运算符和逻辑组合TABLE author, rating FROM Books WHERE status 在读 AND rating 8 SORT rating DESC这里面有几个关键点字符串比较用双引号包裹比如status 在读。数字比较直接写数字rating 8。日期比较最稳妥的写法是date(2026-01-01)后面调用WHERE started date(2026-01-01)。SORT后面跟字段名多个字段用逗号分隔DESC是倒序ASC是正序。有一个新手很容易踩的坑字段名必须严格匹配YAML里的拼写。status和Status会被当成两个不同字段中文名字也尽量保持统一。Dataview的字段匹配是大小写敏感的这一点真的能卡住人半小时。2.4 GROUP BY、FLATTEN与LIMIT分组、展开与限量GROUP BY把结果按字段分组常用来做统计视图。比如按状态分组LIST FROM Books GROUP BY status这会把未读在读读完的书分别列成一组。注意GROUP BY之后原来字段的引用方式会变化比如想显示分组的键要用rows来代表组内所有条目。FLATTEN适合处理数组字段。YAML里如果写了tags: [a, b]或者行内字段tags:: a, bFLATTEN可以把数组展开成多行。典型场景是一个项目笔记里存了多个子任务标签FLATTEN后可以分别展示。LIMIT就是限制输出条数适合只需要最近N条的场景TABLE title, rating FROM Books WHERE status 读完 SORT rating DESC LIMIT 10这一节的内容足够应付80%日常需求了。如果还想了解更复杂的表达式、函数比如length()、replace()、dateformat()可以在笔记里输入dataview代码块后用插件自带的帮助文档查阅语法是带着完整说明的。3. 三个拿来即用的实战模板阅读清单、任务聚合、日记回顾3.1 用Dataview管阅读进度一本书到底读完没有我以前读书笔记都是散着的看没看完得点开目录才知道。后来我统一在每本书的笔记frontmatter里加一组固定字段结构类似这样--- type: book title: 人类简史 author: 尤瓦尔·赫拉利 status: 在读 rating: 0 started: 2026-01-15 finished: cover: ---然后建一个阅读清单.md放这样三块查询TABLE author, started AS 开始时间 FROM Books WHERE status 在读 SORT started ASCTABLE author, rating FROM Books WHERE status 读完 SORT rating DESCTABLE author, started FLATTEN (0: choice(status 读完, 1, 0)) AS dummy FROM Books WHERE status 在读 SORT date(started) ASC LIMIT 5第一块是当前在读的书第二块是按评分排序的已读书单第三块是我用来做最近在读TOP5界面的一块小技巧——通过choice生成一个虚拟字段来控制显示顺序这个思路可以迁移到很多场景。这里要特别强调为什么要用YAML字段来记录状态而不是把在读写在正文里因为Dataview读结构化字段的效率远高于扫描正文而且不容易匹配错。你正文里写了在读还是觉得一般吧如果正文可以全文匹配WHERE 在读就可能误伤用YAML字段则完全不存在这个问题。3.2 任务看板把散落各处的待办聚合到一个页面Obsidian原生的任务列表- [ ]在每篇笔记里是独立的没法跨文件汇总。如果你把任务打散在不同笔记里想统一看今天要干什么用Dataview的TASK查询块最合适TASK FROM Projects WHERE !completed SORT due ASC这会把Projects文件夹下所有未完成任务列出来并按截止日期排序。如果任务行里写明了⏳ 2026-01-20或使用Dataview的行内字段[due:: 2026-01-20]排序会非常准确。我的一个习惯是给任务标签分优先级比如#P0、#P1然后在查询里直接用标签过滤TASK FROM Projects WHERE !completed AND contains(tags, #P0)contains()函数很常用它判断一个列表是否包含某个值。任务的tags属性在Dataview里默认是数组contains(tags, #P0)就能精确匹配。不过提醒一句如果你只做纯任务管理且任务数量特别大几百上千条我更推荐配合Tasks插件来管理因为Tasks插件对任务的解析更完整支持优先级图标、自定义任务状态、周期任务。Dataview的TASK更适合轻量聚合两者不冲突可以配合用。3.3 日记聚合过去一周到底干了什么很多人的Obsidian里有日记文件夹每天写一篇内容包括心情、时间记录、今日完成的事。这些日记如果一篇篇翻复盘效率极低但Dataview可以轻松把最近7天的日记聚合到一个页面TABLE file.day AS 日期, mood AS 心情, focus AS 今日重点 FROM Daily WHERE file.day date(today) - dur(7 days) SORT file.day DESC这里有两个核心知识点file.day如果日记文件名是日期格式比如2026-01-20.mdDataview会自动把这个日期解析为file.day字段可以直接拿来比较和排序。这是Obsidian和Dataview的约定优于配置非常省事。date(today) - dur(7 days)Dataview内置了日期运算dur(7 days)就是时长7天可以相减。这个语法写熟了很多时间查询都很优雅。再进一步如果你在日记的YAML里记了time_spent这样的字段例如工作了4小时写成time: 4可以用SUM()聚合出一周总工时。这里要分享一个我在真实使用中摸索出的操作经验日期的书写一定要遵循YYYY-MM-DD格式比如2026-01-08不要写2026年1月8日或26-1-8否则file.day的自动解析会失败或出错查询结果会直接为空。很多人折腾半天查不到数据八成就是栽在日期格式上。4. 当内置查询不够用用Dataviewjs写自己的逻辑4.1 声明式语法解决不了问题时就该上Dataviewjs了dataview块里写的是类SQL声明式语法优势是简单直观但边界也很明显没法做复杂循环、动态变量、自定义DOM结构、访问文件系统API。比如你想统计过去30天每天写了多少条笔记并输出成折线图数据或者想输出一个按月份分组的卡片式表格声明式语法就累了。这时候就需要dataviewjs代码块。它允许你写JavaScript利用Dataview提供的dv对象直接操作页面数据。4.2 最常用的API速览初学Dataviewjs掌握这几个核心API就够用dv.pages(Books)获取数据等价于声明式里的FROM。dv.current()获取当前笔记的字段。dv.table(headers, values)渲染表格headers是表头数组values是二维数组。dv.list(values)渲染列表。dv.paragraph(text)输出普通段落文本。.sort()、.where()、.groupBy()Js数组或Dataview数组自带的方法。注意dv.pages()返回的不是普通数组而是一个DataArray对象它有自己的.where()、.sort()、.groupBy()方法用法更贴近数据库操作。如果用惯了ES6的Array.prototype.filter这两种方式可以互转.array()方法转普通数组不过DataArray的方法本身大多数场景更简洁。4.3 一个真实案例统计近30天的日记数量并绘图这里给一个我实际用过的例子工作日每天写日记周末断更我想看看近期写作频率有没有下降const days 30; const files dv.pages(Daily).where(p p.file.day); const today dv.date(today); const results []; for (let i days - 1; i 0; i--) { const d today.minus({ days: i }); const hasNote files.some(p p.file.day.toFormat(yyyy-MM-dd) d.toFormat(yyyy-MM-dd)); results.push([d.toFormat(MM-dd), hasNote ? 有 : 无]); } dv.table([日期, 是否有日记], results);这段代码做了四件事获取Daily文件夹下所有笔记并通过.where(p p.file.day)过滤出能正确解析日期的笔记。用dv.date(today)得到今天的日期对象。循环30天用today.minus({ days: i })往前推日期然后判断当天是否有日记。用dv.table()输出。坦白讲这段代码拿到浏览量最大的知识库论坛上也够用了。但我要强调一个坑p.file.day拿到的日期是Luxon DateTime对象直接和字符串比较是永远不等的必须用.toFormat()方法格式化成字符串再比较。这个坑我当年踩了半小时极度崩溃。4.4 Dataviewjs性能需要自己负责Dataviewjs自由度大代价是性能容易失控。比如在循环里调用dv.pages()就是大忌应该先把它提到循环外面存成变量。而且你每次用dv.table()渲染几百行数据时Obsidian的视图会明显卡顿。我的几条经验尽量使用dv.pages()一次拉取然后内存中处理不要反复查。渲染条数超过200条时考虑分组或限制展示必要时用LIMIT或者.take(50)。只对需要的字段做处理不要打印整个p对象那会拖着大量数据。出错时在Obsidian开发者工具CtrlShiftI的Console里看报错信息比对着屏幕干猜强得多。5. 高频踩坑现场查询不出来、卡顿、数据不同步5.1 字段大小写和命名不统一查了个寂寞这是Dataview最频发的错误没有之一。YAML里写了status结果查询写成了Status出来的结果就是空。还有人在不同笔记之间字段写法飘忽不定一篇用rating: 8另一篇用Rate: 8查询时只能命中一半。我的解决思路是建立一套笔记字段规范把它写进自己的模板里。比如读书笔记统一使用title、author、status、rating、started、finished日记统一使用mood、energy、time_spent。让Templater自动生成模板这样每篇笔记的字段结构天生一致。字段名尽量全小写下划线比如time_spent避免大小写问题。5.2 日期格式不规范WHERE怎么都匹配不上日期筛选查不到结果90%是日期格式问题。Obsidian希望日期用YYYY-MM-DD如果你的YAML里写了2026.01.15甚至2026/01/15Dataview解析会出各种意外。我的建议是凡是表示日期的字段统一用YYYY-MM-DD格式例如--- started: 2026-01-15 finished: 2026-02-03 ---然后查询时用date(started)包裹字段参与比较这样最稳TABLE title FROM Books WHERE date(started) date(2026-01-01)5.3 数据更新不及时为什么改了字段视图没变Dataview依赖索引。理论上你改了YAML后页面刷新就会更新但实际使用中偶尔会出现视图迟迟不刷新的情况。特别是批量改了很多文件、或者长时间没重启Obsidian时。我的处理方法是先重开那个包含查询块的笔记切换页面再切回来如果还不行就打开设置里的Dataview配置点击一下Reindex强制重建索引。这个操作基本能解决99%的明明改了却不更新问题。5.4 性能优化全库扫描是大忌笔记量超过5000篇后一个没有FROM限定、包含大量计算的Dataview查询块会明显拖慢打开速度。Dataview默认会缓存索引但每次查询仍然需要遍历、过滤、排序数据量大了自然会慢。优化思路优先级从高到低加FROM限定范围不要全库扫描。比如只查Books文件夹别让Dataview去扫Daily。精简查询块数量。一个页面塞五六个Dataview块且每个都扫全库再快的机器也受不了。合并同类查询、拆到不同页面去。使用Dataview设置里的Refresh Enabled和Refresh Interval把自动刷新周期调长减少实时索引压力。对Dataviewjs缓存结果。可以用模块级变量保存计算结果在一天内不重复计算。考虑换用DatacoreDataview的重写版本如果库继续膨胀。但这不是本节重点先不做展开新用户完全可以从Dataview起步。5.5 插件联动不只是装饰而是自动化Dataview的威力乘以其他插件才真正被放大Templater新建读书笔记时自动插入YAML模板字段零散落。配合Templater的JS能力甚至可以在模板里自动获取当前日期、书名让录入过程台窗化。Tasks插件把任务管理做到极致再用Dataview兜底做多维度聚合。Homepage插件把启动页面做成一个掌控面板放上核心查询块一天开始就知道该做什么。QuickAdd插件用快捷命令快速录入日记、任务项时自动写入对应字段避免手动敲YAML。个人体会别一口气把所有插件流程全自动化。先把Dataview的字段基础和查询练熟用两周时间手动录入确认哪些字段用得最多、哪些查询看得到价值再上Templater和QuickAdd自动化。否则很容易出现自动化模板做了一大堆实际查询需求一变模板全部要返工的窘境。最后分享一点我自己的折腾心得Dataview最反直觉的地方在于它不是让你多记而是逼着你想清楚哪些笔记以后会被我怎么问。每次动手写YAML字段前先问自己一句将来我会按什么条件找这篇笔记——这个问题想明白了字段设计自然就对了。我见过太多人一开始堆了二十多个字段后来发现80%的字段从来没被查询过一次全是无效成本。从最少字段起步按真实查询需求慢慢加才是用Dataview最舒服的路径。