我最早正经把笔记当回事，是因为发现自己的知识散得不像话：电脑桌面一堆临时文档，浏览器收藏夹几百个链接，微信里转存了一堆"稍后读"，聊天记录里还躺着无数条灵光一现的想法。每次真要找点什么，翻半天还未必能找着。后来我试了一圈主流云笔记，记是记下来了，可一想到数据全托管在别人服务器上，心里总不踏实，万一哪天服务调整、账号出问题，几年的笔记说没就没。于是我把目光转向了本地优先的阵营——Obsidian、Joplin、Trilium，这三款工具我陆陆续续都深度用过，踩了不少坑，也攒下不少心得。这篇就把三款工具的选型逻辑、核心操作、插件玩法和实际坑点一次性讲透，给正在纠结"本地笔记怎么选、知识库怎么搭"的朋友一份能直接照着做的参考。
1. 为什么我把笔记从云端迁回本地：数据主权与Markdown的自由
1.1 被"绑定感"逼出来的本地化选择
我在云笔记上吃过大亏。早期用某款老牌云笔记，记了大概两三年，突然某天发现导出格式一团乱，图片链接全失效，表格排版全崩。那时候我才意识到，笔记工具真正的成本不是会员费，是迁移成本——笔记写得越久，你被绑得越死。催生我转向本地工具的直接原因有三个：一是离线可用性，地铁、飞机、信号差的地方照样能读能写；二是文件即资产，笔记说到底就是一堆Markdown文本加图片，不依赖任何专属数据库；三是十年后的可读性，就算工具停止维护，我还有最原始的文件可以打开，不至于血本无归。
所以我把标准定为"本地优先 + 开放格式 + 双向链接 + 插件生态"。Obsidian、Joplin、Trilium恰好都是这个路子，但它们对"本地优先"的理解和实现方式差异非常大，这也是大多数人不知道该选哪款的核心原因。
1.2 三款工具的共性：Markdown、本地存储与开源生态
先看它们的共同底盘。三者都支持Markdown语法，纯文本存储是底线。Obsidian的数据是一个Vault（仓库），本质就是一个普通文件夹，里面放着你的.md文件、附件和.obsidian配置目录。Joplin则是把所有笔记保存在本地的一个SQLite数据库里，每条笔记的正文以Markdown形式存放在独立的.md文件中（在文件系统里能看到）。Trilium采用的是内置的SQLite存储加文档树结构，笔记内容存在数据库里，但它支持随时把单条笔记或整个树导出为Markdown/HTML。
数据存储方式决定了后续的一切玩法，所以这是选型时最不该忽略的点。我的建议是：不要被"双链"、"图谱"这些营销词迷惑，先想清楚你更信任"文件夹+文件"的直觉模式，还是"层级树"的管理模式，再往下选。
2. Obsidian：从零搭建知识库的核心操作与Vault逻辑
2.1 第一次启动：Vault是什么，为什么不能乱建文件夹
Obsidian启动时会让你创建一个Vault。很多人第一次用会懵，不知道Vault和普通文件夹有什么区别。简单说，Vault就是Obsidian的"项目边界"——它把一堆Markdown文件、附件、插件配置都圈在一个根目录里，Obsidian只索引这个根目录内的文件。你在Vault外的文件，哪怕就在你电脑上，Obsidian也不会索引到，也更不会出现在图谱里。
那我为什么不建议一上来就乱建文件夹？因为Obsidian真正强大的是双链和标签体系，如果一开始就按传统思维建一堆"工作笔记/生活笔记/学习笔记"这种固定分类目录，你的笔记系统会很快僵化。Obsidian社区里主流的做法叫PARA或者Johnny Decimal，但我觉得新手最稳的起步结构是三段式：
00-Inbox（所有临时想法、剪藏、闪念都丢这里） 01-Projects（按项目/主题组织，一个项目一个文件夹） 90-Attachments（统一存放图片和附件）这个结构的好处是：Inbox负责"先记下来"，Projects负责"整理沉淀"，Attachments统一管图片。等你笔记多了、双链摸熟了，再逐步调整成适合自己的体系。记住，文件夹是给"检索"用的，双链是给"联想"用的，两者不冲突，但别一开始就让文件夹拖累双链。
顺便说下"obsidian是免费的吗"——个人使用完全免费，它不搞订阅，移动端也能用。下载直接从官网拿安装包就行，Windows、macOS、Linux都有对应的包。
2.2 图片嵌入与图片管理的三种姿势
热词里"obsidian图片怎么嵌入"被搜得很多，这个确实坑。Obsidian里Markdown图片的标准写法是，但新手用起来会遇到几个问题。
我的建议是：图片不要手动敲路径，用粘贴或拖拽。截图之后在笔记里直接Ctrl+V，Obsidian会自动把图片存到你Vault里设置的附件目录，并生成对应的Markdown图片引用。默认情况下它会存在当前笔记的文件夹下，我建议在"设置-文件与链接-附件默认存放路径"里改成之前规划的90-Attachments，这样所有图片集中管理，以后整理文件不会乱。
第二种姿势是相对路径引用：同一Vault内不同文件夹之间引用附件，用相对路径。如果你把笔记和附件放在同一层级，这个写法最稳，跨设备同步也不会丢。
第三种是通过插件增强，比如Image auto upload Plugin可以配合对象存储，把图片自动传到图床。但我的个人建议是：本地优先的场景下，图床能不碰就不碰。图床虽然省空间，但等于把数据又交出去了，还引入了"图片裂掉"的风险。除非你要发布博客，否则优先用本地附件。
2.3 高频快捷键与日常输入习惯
Obsidian老手和新手的操作效率差距，很大程度上是对快捷键的熟悉程度。我日常使用频率最高的几个：
| 快捷键 | 作用 |
|---|---|
| Ctrl + N | 快速新建笔记 |
| Ctrl + P | 打开命令面板，几乎所有操作都能搜到 |
| Ctrl + O | 快速跳转文件，比在文件树里点快十倍 |
| Ctrl + E | 在编辑模式与阅读模式之间切换 |
| Ctrl + Shift + F | 全局搜索 |
| [[ | 输入双链 |
| # | 输入标签 |
最值得养成习惯的是Ctrl + P命令面板——Obsidian里一半的功能都不需要记快捷键，在命令面板里输入中文或英文关键词就能执行。很多新手以为插件装了没效果，其实就是在命令面板里触发的。
我的日常写笔记习惯是：看到好内容，先丢进00-Inbox，不分类、不整理；晚上或者周末统一处理，能归入项目的用双链挂进去，暂时没处的就留在Inbox让Dataview列表展示。真正让笔记库不变成"垃圾堆"的，不是分类技巧，而是这个"先收集、后整理"的节奏。
3. Obsidian插件生态：必装清单与Dataview、PlantUML实战
3.1 我的必装插件清单及理由
Obsidian的核心引擎其实是它的插件生态。基础功能很克制，装完插件才是完全体。社区插件里有几个我认为是"装上即回不去"的级别：
- Dataview：把笔记当作数据库来查询，支持按标签、文件夹、属性筛选列表。这是Obsidian能成为"知识库"而非"笔记文件夹"的关键。
- Calendar + Periodic Notes：日历视图，配合日报/周报/月度笔记模板，适合写日志型知识。
- Templater：模板引擎，比官方模板功能强得多，支持JS脚本动态生成内容。
- Excalidraw：画图/白板工具，适合画架构图、示意图。
- PlantUML：用代码画UML图和时序图，适合记录系统设计。
- Admonition / Callout：在笔记里做醒目的提示框、注意框。
- Style Settings：用于细调CSS样式。
- Omnisearch：比自带搜索更强的模糊搜索。
- Git：自动版本管理，防止误删，写长文特别稳。
- Obsidian Git：配合Git做自动备份，我的整个Vault每天自动提交一次。
我会定期清理插件，不是因为插件越多越好，而是每个插件都会增加启动负载和心智负担。我的原则是：一个需求只留一个最顺手的插件，能不用插件就不装。
3.2 Dataview：把笔记变成可查询的数据库
Dataview值得单独拿出来讲，因为它是Obsidian和普通Markdown编辑器拉开差距的核心。它的本质是在笔记的Frontmatter里写属性，然后用查询语句把符合条件的笔记列出来。
比如我在每篇笔记顶部写：
--- type: 阅读笔记 status: 进行中 tags: [产品, 方法论] author: 张三 rating: 4 ---然后想找出所有"阅读笔记"里评分高于3的，就在任意笔记里写：
TABLE author, rating, status FROM "01-Projects/阅读笔记" WHERE rating >= 3 SORT rating DESC渲染出来就是一张表格，自动汇总所有符合条件的笔记。比手动维护"读书清单"目录高效得多。再比如我想看本周写了什么，可以用：
LIST WHERE date(today) - file.day <= dur(7 days) SORT file.day DESCDataview的上限很高，它的查询语法跟SQL有一些渊源，但不需要真的会SQL。新手可以先从"TABLE+FROM+WHERE"三个关键词开始，慢慢加SORT和GROUP BY。遇到不会的写法，去社区翻例子比自己硬记语法快得多。
3.3 PlantUML、CSS样式与中文社区：插件之外的能力延伸
"obsidian plantuml"和"obsidian 序列图"的热度一直不低，这背后是很多技术人在用Obsidian记录系统设计。PlantUML插件的用法是：装好插件后，在代码块里写PlantUML语法，渲染出来就是图形。例如一个简单的用户登录时序图：
@startuml actor 用户 participant 前端 participant 后端 participant 数据库 用户 -> 前端: 输入账号密码 前端 -> 后端: 发送登录请求 后端 -> 数据库: 校验用户信息 数据库 --> 后端: 返回结果 后端 --> 前端: 登录成功 前端 --> 用户: 进入首页 @enduml这样维护系统文档时，改代码比改Visio图快多了，还方便版本管理。
CSS样式这块，很多新手以为美化Obsidian很难，其实核心就是一个关键词——snippet（代码片段）。在"设置-外观"里打开CSS代码片段开关，它会生成一个snippets文件夹，你往里放任何.css文件，Obsidian就会套上对应样式。比如想给标题换颜色、给表格加斑马纹，一段CSS就能搞定。如果不想手写，直接上Style Settings插件，很多主题允许可视化调节。
还有一个很多人不知道的点：Obsidian有活跃的中文社区和官方中文论坛，任何"XX插件怎么用"的问题，基本都能搜到现成的中文教程，遇到问题先搜再问，能省大量时间。
3.4 AI Agent接入知识库的现状与局限
"obsidian + ai agent 知识库"这类词最近特别火。实际落地的方式大概是几种：一是用官方的AI插件，把笔记内容和本地大模型或云大模型接口做对话问答；二是借助第三方工具把你整个Vault切块向量化，然后用Agent对这些内容做检索增强生成。我试用过几轮，结论是：有价值，但别神化。
最有价值的场景是"对着你的笔记聊天"——比如"我上个月记录的关于XX项目的结论是什么"，它能基于你的笔记内容给出带引用的回答，确实比一个人翻文件夹快。局限在于：笔记量太少时，检索效果不如直接全文搜索；笔记本身的组织和措辞质量直接决定回答质量，如果你的笔记是碎片化的摘抄，AI给出的也是碎片化的拼凑。我的建议是：先把自己的知识库搭到一定规模（至少几百篇规范笔记），再考虑接AI，不然是给玩具接电。
4. Joplin：同步方案、保存路径与"轻量优先"的取舍
4.1 Joplin的数据结构与保存路径设置
Joplin在很多场景下是Obsidian的"轻量平替"，尤其适合不需要复杂双链、但需要稳定多端同步的人。先说最常被搜的"joplin设置保存路径"问题。
Joplin首次启动后的数据默认存放在系统用户目录下的配置文件夹里，比如Windows上是C:\Users\你的用户名\.config\joplin，macOS上是~/.config/joplin。打开后你会看到两个核心东西：一个database.sqlite（笔记索引和元数据），一个resources或files目录（附件和图片），每条笔记正文以.md文件形式存放。想改保存路径，不需要改配置文件，直接在设置里找到"常规-附件目录"或者直接挪动整个配置文件夹，然后重新指向即可。更省心的做法是干脆把整个.config/joplin目录用软链接指向你希望存放的大分区或同步盘。
这里有个容易踩的坑：很多新手试图让Joplin直接读取一个已存在的Markdown文件夹，就像Obsidian打开Vault那样。但Joplin不是这么设计的——它的笔记列表由SQLite索引控制，你手动往目录里塞文件，它不会自动识别，还可能导致索引混乱。如果你要在Joplin和别的工具间迁移内容，正确的路径是用它的"导入/导出Markdown文件"功能，而不是直接把文件夹塞进去。
4.2 多端同步方案怎么选
Joplin的同步机制和Obsidian完全不同。Obsidian本身不带云同步，官方也不托管你的数据，同步方案要么是配置文件指向iCloud/坚果云/OneDrive等网盘文件夹，要么用Git。Joplin则内置了完整的同步引擎，可选方案包括官方推出的Joplin Cloud、Dropbox、OneDrive、Nextcloud、WebDAV、文件系统等。
我实测过几种方案的体验差异：
| 同步方式 | 稳定度 | 上手难度 | 适用场景 |
|---|---|---|---|
| WebDAV | 高 | 中等 | 自建服务或已有支持WebDAV的网盘 |
| Joplin Cloud | 高 | 低 | 愿意付费、想省心的用户 |
| 文件系统/FTP | 看网络环境 | 低 | 局域网内同步 |
| OneDrive/Dropbox | 高 | 低 | 已有对应网盘的Windows用户 |
提醒一点：Joplin同步的是"数据库+附件变更"，不是像Obsidian那样同步"整个文件夹"。所以它对大量文件变更的处理比较稳，但同步时如果经常手动中断，偶尔会出现"笔记冲突"副本。我的习惯是：每台设备上同步前，先让上一次同步完整跑完再做大量编辑，减少冲突。
4.3 Web Clipper和批注的实际体验
Joplin的特色之一是他的Web Clipper浏览器插件，几乎是我用过的最稳的网页剪藏工具。它在Chrome/Edge/Firefox上都有，剪藏时可以选择正文模式、简化模式、截图模式，还能自动标出来源URL。剪完的内容会自动归档到你选定的笔记本里，正文是干净的Markdown，没有乱七八糟的广告和排版。
和Obsidian相比，Joplin的定位更"老实"——它专注于记笔记、多端同步、网页剪藏这三件事，插件生态远不如Obsidian丰富，也没有所谓的双链图谱。如果你只是想找一个"能多端同步、能存网页、能快速搜索"的本地笔记工具，Joplin比Obsidian更省心，因为它不需要折腾插件和同步方案，开箱即用。
但它也有明显的短板：层级分类只有两级（笔记本+子笔记本），组织大量长文时会觉得结构扁平；编辑器本身偏简洁，对复杂表格、嵌入内容的支持比较弱；App端功能也偏基础。我目前把Joplin当成"收件箱和剪藏库"用：网页文章、微信文章、临时灵感都先进Joplin，定期筛选有价值的内容再整理进Obsidian。
5. Trilium：层级树结构的价值，以及它的陡峭学习曲线
5.1 为什么层级树反而适合某些知识场景
Trilium是三款里最"异类"的一个。它的核心是层级树（Note Tree）：所有笔记是一棵可以无限嵌套的树，你可以拖拽任意节点来调整层级，一棵子树就是一个主题/项目/领域。很多人第一次打开Trilium很不适应，觉得这是"老式文件夹结构的加强版"，但在某些场景下这个设计极为高效。
最典型的是"构建一个持续生长的大型知识体系"，比如我在用Trilium整理技术方案库：顶层是"技术架构"、"后端开发"、"前端开发"、"运维部署"、"项目管理"，每一层继续往下细分，最终形成一颗结构严谨、逻辑清晰的树。比起Obsidian靠标签和双链"从下往上"生长，Trilium是"从上往下"规划，适合那种目标明确、骨架清晰的长期知识库。
还有一点Trilium做得很强：单条笔记支持不同"类型"，比如普通文本、表格、画布、甚至是代码文件，同一棵树里可以混用，嵌套关系自由。它的"属性"系统也很有意思，你能给任意笔记打上键值对属性，比如author:: 张三、date:: 2024-01-01，然后通过内置的高级搜索按属性过滤整棵树。
5.2 脚本扩展与中文支持的真实体验
Trilium内置了一套脚本引擎，支持用JavaScript写脚本来自动化处理笔记。比如我可以写一个脚本，把指定子树下的所有笔记按日期批量加上属性，或者自动生成周报汇总。脚本功能的上限很高，但这也意味着它的学习曲线比Obsidian插件更陡——插件是别人封装好的能力，脚本则是你自己动手造轮子。对多数人来说，这个功能属于"知道存在就好"，真正常用的其实还是树形结构、属性和搜索。
中文支持方面，新版Trilium对中文的兼容已经有很大改善，内置编辑器显示中文没问题，搜索也没问题，但界面翻译的完整度依然不如Obsidian。社区第三方主题和插件数量也比较少，尤其是和Obsidian相比，简直是小众中的小众。
5.3 Trilium的硬伤：同步、导出与生态差距
Trilium自带一套同步机制，原理是所有客户端直连同一个服务端实例，服务端保存主数据，客户端同步副本。这种方式在局域网或自托管服务器上很稳定，但如果你没有一台长期在线的服务器，多端同步这件事会比Obsidian和Joplin麻烦不少。
另一个硬伤是导出。Trilium虽然能导出Markdown/HTML，但导出后的结构和原层级树并不能完全对应，附件路径偶尔会乱。我在一次想从Trilium全量迁移到Obsidian时折腾了很久，最终效果也只是"内容都出来了，但树形关系变成一堆扁平文件"。这意味着它更适合"老老实实待在里面长期用"，而不是频繁迁移的工具。
生态差距也是绕不开的。Obsidian有几百个社区插件和庞大的教程站，Joplin有稳定的剪藏和同步，Trilium的社区规模就小得多，遇到问题能参考的资料有限。如果你不是被它的层级树设计强烈吸引，我一般不建议新手直接上手Trilium。
6. 三款工具横向对比与我的迁移路线参考
6.1 核心差异速览
| 维度 | Obsidian | Joplin | Trilium |
|---|---|---|---|
| 数据存储 | 本地文件夹 + .md文件 | SQLite + .md文件 | SQLite + 文档树 |
| 核心组织方式 | 双链 + 标签 + 文件夹 | 两级笔记本 + 标签 | 无限层级树 |
| 离线可用 | 完全离线 | 完全离线 | 完全离线 |
| 官方云同步 | 无，需自配 | 多种方案内置 | 需自建服务端 |
| 插件生态 | 极丰富 | 有限 | 很少，有内置脚本 |
| 学习曲线 | 中等 | 低 | 较陡 |
| 移动端体验 | 可用，配置有门槛 | 成熟稳定 | 较一般 |
| 适合人群 | 爱折腾、需要双链和插件的人 | 追求省心、多端同步稳定的人 | 复杂体系、自托管玩家 |
用一句话总结：Obsidian上限最高，Joplin最省心，Trilium最有结构感。这三者解决的问题并不完全相同，不用强行分个高下。
6.2 我最后是怎么分工的
我现在的工作流不是三选一，而是让它们各自干擅长的事：
- Obsidian是主知识库，所有长期笔记、项目笔记、阅读笔记都在这里，双链和Dataview负责把碎片关联起来。
- Joplin是收件箱和剪藏库，网页文章、临时想法先进Joplin，定期清理归档，价值高的内容再"提炼"成Obsidian笔记。这里的关键是，不是简单复制粘贴，而是用自己的话重新组织一遍。
- Trilium目前保留一套长期技术方案库，因为它那棵树的层次感太适合放方案文档。虽然维护成本有点高，但在那一棵树上找东西确实快，我也不打算把它迁移出去了。
这么分工之后，我发现每个工具都在干它最顺手的事，反而比"选一个工具搞定一切"更舒服。代价是同步了两套甚至三套体系，但笔记这种低频高频混合的场景，"数据安全、找得到、写得出"永远比"统一入口"更重要。
6.3 给新人的一条建议路线
如果你刚开始从云笔记迁移到本地，我的建议是先不要碰Trilium。它的课程感和结构感固然好，但对新手来说容易变成"为了整理而整理"，大量时间花在维护树形结构上，挤占了真正记笔记的时间。
第一步，先用Obsidian建一个最简单的Vault，只做三件事：写日记、随手记想法、用双链链接相关笔记。第二步，等笔记积累到一百篇左右，开始引入Dataview和Templater，用自动化替代手动分类。第三步，如果你的网页剪藏需求变多了，再考虑Joplin作为外围系统。至于Trilium，等你的知识体系复杂到"文件夹+双链已经管理不过来"、且你有自托管服务器时，再回头研究也不迟。
我在实际使用中还有一个体会：无论工具怎么换，真正决定知识库价值的不是工具，是你有没有养成"定期回顾"的习惯。我每隔两周会把Inbox清空一次，每个月底把当月新笔记快速扫一遍，把散落的碎片用双链串起来。这个习惯比任何插件都值钱，工具只是在帮你降低执行的成本而已。
