属性 Properties：结构化元数据

正文回答「笔记里写了什么」，属性回答「这篇笔记是什么」。给笔记加上日期、状态、作者这类结构化字段，你的仓库就从一堆文本进化成了可筛选、可统计的小型数据库。本章讲属性的写法、类型系统和实际用法。

什么是属性，写在哪

属性（Properties）以 YAML 格式写在笔记最顶部的两条三横线之间（俗称 frontmatter）：

---
title: Transformer 论文精读
date: 2026-10-01
status: 已读
rating: 4
tags:
  - 论文
  - 深度学习
authors:
  - Ashish Vaswani
link: "[[注意力机制]]"
---

添加属性的几种方式：命令面板运行 Add file property；快捷键 Ctrl+;（macOS 为 Cmd+;）；或在文件最开头手动输入 ---。添加后 Live Preview 顶部会出现可视化的属性编辑区，属性名和值都可以点选修改，不必手写 YAML。

三个默认属性要认识：tags（标签）、aliases（别名，永远是列表格式）、cssclasses（给单篇笔记挂 CSS 样式类）。旧的 tag、alias、cssclass 单数写法已废弃，导入旧笔记时注意统一成复数形式。

属性类型系统

每个属性名对应一种类型，类型决定取值方式和检索行为。点击属性名旁的类型图标可修改；同一属性名在全库共用一种类型。

书写时两个坑要避开：属性值里的双链必须加引号，如 link: "[[注意力机制]]"，否则 YAML 会解析失败；数字属性必须是字面量数值，不能写表达式。日期属性还有个彩蛋——启用 Daily notes 核心插件后，日期属性会自动变成可点击的链接，直达当天的日记。

检索属性：让元数据干活

属性真正的威力在检索环节。全局搜索支持专门的属性语法：

[status]                  → 有 status 属性的所有笔记
[status:已读]             → status 值为「已读」的笔记
[status:已读 OR 在读]     → 值为两者之一的笔记
[rating:null]             → status 属性存在但没填值的笔记

属性搜索可以和普通关键词、操作符组合，比如 tag:#论文 [status:在读] 找「在读状态的论文笔记」。在 Bases 数据库视图里，属性更是直接变成表格列和筛选条件——这是下一阶段的内容。

一套实用的属性设计

属性设计的原则是少而准：每加一个字段都要问「我真的会按它筛选吗」。下面是按笔记类型推荐的起步模板：

配合模板使用体验最佳——在模板文件里预置好属性骨架，新建笔记时一键填入。一个读书笔记模板的属性部分：

---
tags:
  - 读书
status: 在读
rating:
author:
date: "{{date}}"
---

属性的边界与注意事项

几条来自官方文档的边界说明，帮你避免期望落差：

• 不支持嵌套属性的可视化编辑，想用嵌套结构请切到 Source mode 直接写 YAML。
• 不支持批量编辑，大量修改建议借助属性视图（Properties view）重命名，或用脚本、社区插件处理。
• 属性里不渲染 Markdown，它被刻意设计为「原子化的小信息」，长内容请放正文。
• 属性在文档中的显示方式可在 设置 → Editor → Properties in document 里改为 Visible（默认）、Hidden 或 Source。
• 全库属性一览可用核心插件 Properties view（属性视图）查看，右键可重命名属性——重命名会同步更新所有笔记。

新手常见弯路是走两个极端：要么一个属性都不用，仓库回归「一堆文本」；要么一上来设计十几个字段，每天被填表压垮。正确姿势是从两三个字段起步（比如 status 和 date），等某个筛选需求真实出现时再加新字段。属性是给未来的检索行为铺路，不是给当下增加仪式感。

属性视图：全库字段的管理台

当仓库里有几十种属性时，你需要一个总览入口——这就是核心插件 Properties view（属性视图）。它在右侧栏列出全库所有属性名及各自的使用次数，点进去能看到所有包含该属性的笔记；右键属性名可以直接重命名，重命名会同步更新全库所有笔记里的这个字段——批量改名从此不需要脚本。

属性视图还是「字段卫生检查」的利器：翻一遍属性列表，你会立刻发现那些只被两三篇笔记使用的孤儿字段（当初一时兴起建的）、语义重复的字段（date 与 created 并存）、以及拼写不一致的变体（status 与 Status）。每月巡检一次，字段体系就能保持干净。重命名的批量修改虽然官方支持，但涉及大量笔记时建议先在几个文件上验证效果。

属性驱动的高级组合

属性的价值随组合方式指数增长，给三个进阶方向：

组合一：属性 + Bases = 自建应用。 读书库、项目管理、文献库的本质都是「属性字段 + 视图配置」。先设计字段（status、rating、deadline……），再建 Base 视图（看板、表格），你就用纯文本搭出了一个专属的小型应用。字段设计先行，视图是自然结果。

组合二：属性 + Dataview = 自动报表。 「本月新增笔记数」「平均评分」「逾期项目清单」这类统计，本质都是对属性的聚合查询。属性类型定得准（日期就是日期、数字就是数字），查询才不会因类型混乱而漏数据。

组合三：属性 + 模板 = 零成本录入。 结构化最大的敌人是录入麻烦。把预置属性骨架放进模板，配合 Templater 的动态变量自动填日期，录入成本降到「改两个空」。录入越轻松，数据越完整，检索越可靠——这是一个正向循环。

反过来说，属性体系的失败几乎都源于「设计过度」：字段太多、含义模糊、类型混乱。定期用属性视图巡检、按真实筛选需求增删字段，这套系统能陪你走很多年。

从 YAML 角度理解属性

对愿意深入一层（尤其程序员读者）的用户，理解属性的存储本质有额外收益：属性就是笔记头部的一段 YAML 文本，随 .md 文件存储，没有独立数据库。这意味着：批量修改可以用任何文本工具（VS Code 全局替换、sed、Python 脚本）；Git 能对属性变更做精确版本跟踪；JSON 写法也被接受（Obsidian 会读取并转为 YAML 保存）。唯一要小心的是 YAML 语法本身——冒号后必须有空格、列表用短横线、特殊字符加引号，这些细节在模板和批量脚本中尤其容易出错，出问题时切到 Source mode 检查原文即可定位。

二十分钟给仓库加上属性系统

照这条路线走，二十分钟后你的仓库就有了第一批结构化字段。第 1-5 分钟：确定首批字段——只选两个：status（取值固定三到四个，如 在读/已读/想读）和 date（日期类型）。把你最常筛选的那类笔记定为试点对象（读书笔记、项目笔记均可）。第 6-12 分钟：给试点类的五到十篇笔记补上这两个属性——快捷键 Ctrl+; 逐篇添加，顺手在 Live Preview 顶部把 status 的类型点成 Text、date 的类型点成 Date。第 13-16 分钟：验证检索——搜索框输入 [status:在读] 看命中是否符合预期；有 Bases 的再建个小表格视图按 date 排序。第 17-20 分钟：固化——把这两个字段写进对应类型的模板（读书模板、项目模板各一份），以后新建笔记自动带字段；最后打开属性视图看一眼 status 的全库分布，确认没有异常值。

二十分钟结束时的成果：一种笔记类型有了结构化字段、一条可用的属性检索、一个自动带字段的模板。这就是属性系统的最小可用形态——接下来只需等待真实的筛选需求出现，比如「想按评分排序」时再加 rating，「想按作者聚合」时再加 author。字段永远跟着需求走，而不是跟着想象力走，这个秩序比任何字段设计技巧都重要。

延伸阅读：属性批量清理时正则是最锋利的工具，正则表达式从入门到精通 值得常备案头；对程序员读者，Claude Code 完全指南 里「结构化数据驱动工作」的思路与属性系统高度共鸣。

本章由 WorkBuddy 原创整理，功能行为依据 Obsidian 官方帮助文档。