68 lines
4.7 KiB
Markdown
Executable File
68 lines
4.7 KiB
Markdown
Executable File
---
|
||
url: https://www.skyue.com/22040623.html
|
||
title: Obsidian 和 Logseq 对比 - 拾月
|
||
date: 2025-08-20 15:21:09
|
||
tag:
|
||
summary: 用了 2 年 Obsidian，Logseq 以前也知道并试用过，当时只有 web 版，稳定性差就没关注了。
|
||
created: 2025-08-30T11:44
|
||
updated: 2025-09-22T13:26
|
||
---
|
||
用了 2 年 Obsidian，Logseq 以前也知道并试用过，当时只有 web 版，稳定性差就没关注了。不久前看了 Randy Lu 关于 Logseq 的[视频分享](https://www.youtube.com/watch?v=DxoGJBb1mWQ)，被吸引到了，于是试用了 2 周。这期间只用 Logseq，没用 Obsidian。
|
||
|
||
现在，想基于经验分析下二者的功能差异及未来的可能的迭代方向。需要说明的是，这不是一个教程，但如果你正在试用这两个软件，并在犹豫选择哪一个，本文或许能提供一些视角。
|
||
|
||
这两个软件共同主打的特点是：本地存储 + 文本文件。这对在意数据安全、数据可迁移性的用户（比如我）来讲，非常有吸引力。
|
||
|
||
它们的核心差异点有两个：
|
||
|
||
1. Logseq 强制使用大纲视图，Obsidian 是自由格式的 markdown 文档
|
||
2. Logseq 没有文件夹结构，Obsidian 有文件夹结构。
|
||
|
||
**一、首先讲讲自由格式与强制大纲带来的影响**
|
||
|
||
Logseq 强制使用大纲视图，其实就是 block 优先，先有 block，然后 block 组成 page，并且 block 还有层级的关系。
|
||
|
||
Obsidian 自由格式，就是 page 优先，当它想去支持 block 的时候，只能从段落出发，每一段是个 block，段落间当然也没有层级关系。（[官方文档介绍](https://publish.obsidian.md/help-zh/%E4%BD%BF%E7%94%A8%E6%8C%87%E5%8D%97/%E5%9D%97%E9%93%BE%E6%8E%A5%E4%B8%8E%E5%9D%97%E5%BC%95%E7%94%A8)：前后有空行包围的东西就是 block）。
|
||
|
||
从通用性来讲，Obsidian 的自由格式，其实兼容 Logseq 大纲视图。网上有很多人分享二者共用一个库的方案，无一例外的都是以 Logseq 库为准，然后让 Obsidian 去兼容 Logseq，充分佐证了这一点。
|
||
|
||
以 block 为例，前方讲 Obsidian 的 block 是基于段落的，但大纲带也是支持的，如下图所示。
|
||
|
||
|
||
|
||
Obsidian 大纲中的反向链接
|
||
|
||
相比 Logseq 的 block，Obsidian 的 block 有两个问题：
|
||
|
||
* Logseq 能直接在反向引用中编辑和操作（比如点击链接）内容，Obsidian 则必须跳转到原文档才能编辑和操作。
|
||
* Logseq 的`#`标签和 `` 引用，都是作用于块的属性，通过 query 能直接查询到块，Obsidian 通用 dataview 的 query 只能查询到 page。
|
||
|
||
尤其是第 2 条，对 task 的管理非常重要。事实上，Obsidian 的 dataview 社区[已经在计划实现相关功能](https://github.com/blacksmithgu/obsidian-dataview/issues/874)了。
|
||
|
||
再看看 Logseq，因为是强制大纲，所以不适合写长文，有趣的是，Logseq 社区呼声第二高的 Feature Request 就是支持[长文写作](https://discuss.logseq.com/t/longform-writing-in-logseq/3527)。
|
||
|
||
这个帖子对 Logseq 应该如何处理长文 block 给出的建议，就是 Obsidian 基于段落的方案。
|
||
|
||
按照这个畅想，Logseq 支持定义 page 的类型，一类是大纲视图 page，一类是长文视图 page。
|
||
|
||
长远来看，Obsidian 在自由格式上支持更友好的 block 是顺理成章的事，但 Logseq 在现有强约束的情况下去支持自由格式的长文，需要打破框架。不清楚 Logseq 团队是否会考虑支持长文（目前 roadmap 中还看不到），但这确实是我无法放弃 Obsidian 唯一的原因。
|
||
|
||
我个人比较期待二者最后殊途同归，Obsidian 更好的支持 block，Logseq 打破框架支持长文写作。
|
||
|
||
**二、再谈谈文件夹支持**
|
||
|
||
这一点，同样体现了 Obsidian 对 Logseq 的兼容。
|
||
|
||
至于哪个更好，这个见仁见智，我倾向于 Logseq 简化文件夹的方式，减轻分类的压力。Logseq 的页面支持 [namespace 层级](https://www.skyue.com/22072311.html)，可以实现类似文件夹的功能。但需要注意，这是非常定制化的能力，离开了 Logseq 这样的关系就丢失了，所以，如果考虑数据的可迁移性，这个功能应该慎重使用。
|
||
|
||
**三、我最终的选择**
|
||
|
||
我希望在笔记软件中写长文，Logseq 无法完全替代 Obsidian，虽然 Obsidian 的大纲能力比 Logseq 弱但也完全够用，所以本着少折腾的原则，继续使用 Obsidian。但在使用习惯上，会把 Obsidian 中的 daily note 大纲化。
|
||
|
||
哪天 Logseq 支持长文了，会考虑迁移。也许那一天，Obsidian 的 block 能力也能与 Logseq 并驾齐驱了。
|
||
|
||
最后，本文使用 Obsidian 写成。
|
||
|
||
## 相关阅读
|
||
|
||
* [Logseq 中 page、block 和 namespace 的用法](https://www.skyue.com/22072311.html) |