Obsidian 和 Logseq 对比
用了 2 年 Obsidian，Logseq 以前也知道并试用过，当时只有 web 版，稳定性差就没关注了。不久前看了 Randy Lu 关于 Logseq 的视频分享，被吸引到了，于是试用了 2 周。这期间只用 Logseq，没用 Obsidian。
现在，想基于经验分析下二者的功能差异及未来的可能的迭代方向。需要说明的是，这不是一个教程，但如果你正在试用这两个软件，并在犹豫选择哪一个，本文或许能提供一些视角。
这两个软件共同主打的特点是：本地存储 + 文本文件。这对在意数据安全、数据可迁移性的用户（比如我）来讲，非常有吸引力。
它们的核心差异点有两个：
- Logseq 强制使用大纲视图，Obsidian 是自由格式的 markdown 文档
- Logseq 没有文件夹结构，Obsidian 有文件夹结构。
一、首先讲讲自由格式与强制大纲带来的影响
Logseq 强制使用大纲视图，其实就是 block 优先，先有 block，然后 block 组成 page，并且 block 还有层级的关系。
Obsidian 自由格式，就是 page 优先，当它想去支持 block 的时候，只能从段落出发，每一段是个 block，段落间当然也没有层级关系。（官方文档介绍：前后有空行包围的东西就是 block）。
从通用性来讲，Obsidian 的自由格式，其实兼容 Logseq 大纲视图。网上有很多人分享二者共用一个库的方案，无一例外的都是以 Logseq 库为准，然后让 Obsidian 去兼容 Logseq，充分佐证了这一点。
以 block 为例，前方讲 Obsidian 的 block 是基于段落的，但大纲带也是支持的，如下图所示。
相比 Logseq 的 block，Obsidian 的 block 有两个问题：
- Logseq 能直接在反向引用中编辑和操作（比如点击链接）内容，Obsidian 则必须跳转到原文档才能编辑和操作。
- Logseq 的
#标签和 `` 引用，都是作用于块的属性，通过 query 能直接查询到块，Obsidian 通用 dataview 的 query 只能查询到 page。
尤其是第 2 条，对 task 的管理非常重要。事实上，Obsidian 的 dataview 社区已经在计划实现相关功能了。
再看看 Logseq，因为是强制大纲，所以不适合写长文，有趣的是，Logseq 社区呼声第二高的 Feature Request 就是支持长文写作。
这个帖子对 Logseq 应该如何处理长文 block 给出的建议，就是 Obsidian 基于段落的方案。
按照这个畅想，Logseq 支持定义 page 的类型，一类是大纲视图 page，一类是长文视图 page。
长远来看，Obsidian 在自由格式上支持更友好的 block 是顺理成章的事，但 Logseq 在现有强约束的情况下去支持自由格式的长文，需要打破框架。不清楚 Logseq 团队是否会考虑支持长文（目前 roadmap 中还看不到），但这确实是我无法放弃 Obsidian 唯一的原因。
我个人比较期待二者最后殊途同归，Obsidian 更好的支持 block，Logseq 打破框架支持长文写作。
二、再谈谈文件夹支持
这一点，同样体现了 Obsidian 对 Logseq 的兼容。
至于哪个更好，这个见仁见智，我倾向于 Logseq 简化文件夹的方式，减轻分类的压力。Logseq 的页面支持 namespace 层级，可以实现类似文件夹的功能。但需要注意，这是非常定制化的能力，离开了 Logseq 这样的关系就丢失了，所以，如果考虑数据的可迁移性，这个功能应该慎重使用。
三、我最终的选择
我希望在笔记软件中写长文，Logseq 无法完全替代 Obsidian，虽然 Obsidian 的大纲能力比 Logseq 弱但也完全够用，所以本着少折腾的原则，继续使用 Obsidian。但在使用习惯上，会把 Obsidian 中的 daily note 大纲化。
哪天 Logseq 支持长文了，会考虑迁移。也许那一天，Obsidian 的 block 能力也能与 Logseq 并驾齐驱了。
最后，本文使用 Obsidian 写成。
文章对于二者的对比，对我很有启发，我在 obsidian 上同时实践类似于 daily note 的周期笔记，以及 PARA，感觉挺舒服的：
https://zhuanlan.zhihu.com/p/640042778
你这个写的好详细👍
我也基本在用 PARA，但非常轻量，不太重整理，啥都依赖搜索和双链。
PARA 很大一部分在日记中记录了，所以也不太需要整理！
好巧我也看过 Randy Lu 的这期视频，目前我主要是以 Logseq 写日记和灵感，Obsidian 的多端丝滑流畅一直让我有点摇摆，其次觉得自己的写作水平较难以一次性生成长篇的内容，所以目前还是在使用以 block 为主的 logseq，毕竟 Obsidian 主要是以 Page 为主，以无序列表代替 Block 的大纲感觉还是差了不少意思。不知道博主平日里的日记以及灵感主要是怎么记录下来的（memos 和 Flomo 也使用过，但都觉得差点意思），如果博主有分享记录方式的话，希望能够学习学习，谢谢啦～
另：无意间进入博客，感觉氛围和字体非常棒，赞一个👍👍
是的，Obsidian 的 Block 体验差不少。
所以，我用 memos 收集灵感，然后用脚本下载到 Obsidian 库，每条 memos 保存为一篇笔记。定期在 Obsidian 中整理这些 memos，该删的删，该扩展的扩展，以及打上 tag，做双链关系。
总的来讲，基于 Page，实现原子笔记。
我在 Obsidian 也用 Daily Note，但 Daily Note 只记录当天 todo、每日总结（偏流水账类型）、往年今日（用 dataview 查询）。灵感 / 知识类的笔记不放 Daily Note。
谢谢博主的回复！你的写作排版好赞，果然是习惯 Obsidian 的人，我的 Logseq 习惯一写出来就是一大段…😂
有几个疑问还请指教：
1. 记流水账 Daily Note 的话，不怕污染知识库吗？
2. 如果 memos 太短的话，我总觉得是不是太占用文件数了（总觉得一个 md 文件就应该尽量多一些内容，可能是纸质笔记的后遗症）
3.Logseq 的模式是偏园丁型的，Page 无需刻意的分类，但 Obsidian 是以文件夹式管理的，当文件数量比较大的话，文件分类反而成了一个比较大的工作量，比如博主脚本导出的 memos 库，在归类上有什么高见吗？这一直是比较困扰我的地方。
上一条不知道为什么有序列表丢了…
直接一条条回复：
1、我使用目录做大的领域区分，加上 Obsidian 的搜索、图谱都支持目录筛选功能，能解决污染问题。我的目录按如下方式组织：
（1）日记：即 Daily Note，下面按年月组织子目录。
（2）博客：发在博客的文章，下面分文章、周刊、页面三个子目录，文章和周刊对应本博客的两个大分类。
（3）笔记：即所有知识类笔记，不分子目录
（4）摘录：按来源工具分子目录，具体有：
微信读书：有 Obsidian 插件支持导出，一本书一条笔记。
hypothesis：一款网页标注工具，有 Obsidian 插件支持导出，一个网页一条笔记
Omnivore：是一款稍后阅读 + 标注的工具，有 Obsidian 插件支持导出，一个网页一条笔记
memos：自己写脚本导出
总体而言，我按功能组织目录，不用纠错一条笔记应该放在哪。工作流大概是：
（1）摘录目录是最需要整理的部分，它本身只是一个缓冲，我通常将好的摘录内容复制一份到笔记目录作为永久的知识笔记，并且往往会用自己的语言进行重写，再用一条引用链接关联到原始的摘录笔记。（很长的，涉及多主题的接录，比如读书摘录，也会创建多条知识笔记，关联到原始的摘录笔记）
（2）笔记目录作为主要知识库，我不分子目录，全部使用标签进行分类，可以一对多，使用起来方便，不用纠错分类问题。同时，我有尝试 MOC 组织笔记，但目前做的也不太好。
（3）输出都放在博客目录下。
（4）日记很纯粹了。
2、对，我以前也这样，觉得短内容建一条笔记不好。这是一个纯粹的观念 / 心理感受问题，现在已经克服了，不必让这个观念成为工作使用的阻碍。我有些一句话笔记，甚至没有正文，直接写在标题中就行了。
实际上，我现在觉得建一条新笔记有些好处：
（1）强迫判断一下，一条短内容有没有价值，没有价值就删除掉。
（2）如果有价值，应该适当的扩展一下，或与其它的笔记形成关联。短内容最典型的就是名言，但名言都是一些大道理，如果要使用它，最好是与一些案例进行关联，可以与一些案例笔记进行关联。
3、目录问题在 1 中阐述了。
认真读了很多遍，受教了，非常非常感谢！
我觉得有从 Logseq 转到 Obsidian 的动力了（差生文具多系列）
我也分享下我的实践：
我采用两套系统，一个是知识管理系统，另一个是周期笔记，前者以项目 / 领域 / 资源为维度，进行知识管理，后者以时间为维度，进行任务 / 目标 / 时间管理。这样自然而然分开了两个系统，但是二者之间通过标签相互索引！
知识管理：采用 PARA 系统
Projects -> 项目是与目标相关的一系列任务，有截止日期 Areas -> 领域是一种活动领域，需要在一定时间内保持一定的标准 Resources -> 资源是持续感兴趣的话题或主题 Archives -> 存档是来自上述三个类别的非活动条目周期笔记
长期：自顶向下，专注于长期的目标短期：自底向上，专注于短期的任务- 日常：捕捉想法洞见，实现自我觉察；耗时统计，确保聚焦于项目
- 日记
其中 PARA 越靠近 Projects，它的可操作性就越高；周期笔记越长期，它的可预测性就越低；
这两套系统相当于制造了两个上下文，让我保持聚焦
一个是基于时间的（周期笔记），即我到达某个时间节点，我就基于对应周期笔记作业，且笔记中有足够的上下文；
另一个是基于主题的（PARA），即我想对某个主题进行调查研究的时候，我就基于对应主题的索引（README.md）作业，且笔记中已经收集了不少上下文；
完整的实践请前往：https://zhuanlan.zhihu.com/p/640042778
谢谢博主的回复！你的写作排版好赞，果然是习惯 Obsidian 的人，我的 Logseq 习惯一写出来就是一大段…😂
有几个疑问还请指教：
记流水账 Daily Note 的话，不怕污染知识库吗？如果 memos 太短的话，我总觉得是不是太占用文件数了（总觉得一个 md 文件就应该尽量多一些内容，可能是纸质笔记的后遗症）Logseq 的模式是偏园丁型的，Page 无需刻意的分类，但 Obsidian 是以文件夹式管理的，当文件数量比较大的话，文件分类反而成了一个比较大的工作量，比如博主脚本导出的 memos 库，在归类上有什么高见吗？这一直是比较困扰我的地方。obsidian 什么时候以文件夹管理了？ob 你可以完全一个文件夹都不建，用标签等方式管理 -- 某些 ob 使用者是完全不建文件夹，文档都 “散掉” 的，就靠标签、链接等将知识点 “凑” 起来。所谓文件夹结构，就是树型结构，这种方式有优点也有缺点，优点是层次分明，分类清晰 -- 这种结构非常适合 “强迫症患者”，缺点就是有些东西是似是而非，不太好归类，而且过多或过深的目录结构，在使用和管理上也麻烦。所以我个人使用经常是使用 “矮树型”，即使用不超过两层文件夹归类方式管理文档。而像 logseq 这种扯蛋的创新，完全就是削弱了 markdown 的文档能力（相较的，ob 才是将 md 这种文档的可能性发挥到极致的软件），还多此一举地弄出个 block 概念。logseq 就只适合记下日记、周期什么的，就如它的名称 logseq 中的 log 日志一般，它的适用范围就只在日志这块，其他超出这范围的使用，只能在使用上非常难受！
最近几天就在纠结使用那个呢，obsidian 使用过一段时间，很酷，但是也很折腾。想试试 logseq。感谢分析。👍
界面和交互的简洁性，Logseq 更胜一筹。
从折腾来讲，都挺折腾，但形式不一样。
1. 我怎么记得 Obsidian 可以链接到块啊。
2.Logseq 没有文件夹这也太激进了吧，为什么要把传统的文件管理方式全盘否定掉。（管理文件本身是一个非常耗费精力的事情，Logseq 干脆不管理）对于新手来说很容易一脸懵逼。
3.Logseq 的审美比 Obsidian 差一大截。😂
Obsidian 是 UI 大改版之后好看了，感觉刚开始的 UI 也不好看。
Logseq 的 UI，甚在简洁，当然，也是因为没有文件管理面板带来的简洁。
文件管理这部分，其实我个人是更喜欢纯标签管理的，像 Gmail 那样，没有分类的压力和纠结（我现在实际也只分了很少几文件夹），但这个方式确实非常依赖 app，不通用，如果离开了 app，在电脑文件系统看就很麻烦。
觉得 logseq 激进一点应该没有什么所谓，毕竟开源，不会太影响可迁移性。
下一个软件可以借鉴 logseq 的源码
也很期待，笔记还能做成什么样。
从传统的印象笔记到 Notion 的数据库，再到 RR 的双链 + block。很难想像还能做成什么样，哈哈。
Obsidian 不强制双向链接主导的文件索引模式，增加了文本的「通用性」，日后有合适的软件，迁移成本较低。
我现在是把永久笔记存放在目录文件夹中，子弹笔记和文献笔记都沿用双向链接架构的文件管理模式。
保证永久笔记迁移的低成本。
另外，更看好 Obsidian 的商业模式和社区活力。
感觉双链已经成为笔记软件的标配，未来的兼容性应该不是问题，没有 Obsidian，其它软件也会支持。
但实际使用中，我还是倾向于文件夹 + 标签管理笔记，双链不作为管理 / 索引手段，仅仅真的是一个笔记要引用另一条笔记时使用。
写的挺深入的，正在用 logseq 的我准备去试试 obsidian 看看。
有个问题是，logseq 的 #和 [[]] 只能找到页面啊，不能作用于块吧？
能使用对块的引用啊，官方文档上有，在官方文档上搜索 “块引用” 就行
是的，logseq 的块只有 (())
当长文章作为出入链显示在某页面的下方，想想就摇头。
logseq 显示模式还是略显简陋。
logseq 页面下方显示出入链，通常不会折叠。
当一或几篇不怎么分块（block）的长文章作为出链显示在某页面的下方，那酸爽。。。
当下 logseq 的显示模板，太简陋，使得 zhangw
这个可以在 edn 配置文件中设置，反链显示几层关系。默认显示了匹配块的子节点，如果有大量并列的子节点，就会造成你讲的现象。解决上：
1、可以考虑设置不显示子节点，或者
2、有意识的避开写大量并列子节点，我用这个方法，如果有大量子节点，一般会再分组，弄成孙结点，不会在反链中呈现。
这个部分 Obsidian 确实处理的巧妙一些，有三个选项：只显示标题、只显示匹配块、显示匹配块的上下文。并且这三个选项随时切换，不用在设置中写死。
重度使用一年多 ob 了，最近被朋友安利 logseq 还在入坑，摸索到了这篇文章
作者把特点和问题都梳理得好清楚！而且最后选择的解决方法也一致哈哈，还是 ob 为主，思考怎么兼容 logseq 一起使用
希望作者对 ob 未来会改进块体验的畅想会成真！我也是觉得，如果 ob 现在着手改进块引用，其实也没有无法解决的障碍。把代码隐藏显示（像 callout、表格那样做成及时渲染）；把块和页解除绑定、每个块有独一无二的标识码，就差不多可以了
ob 的客户端迭代明显慢下来了，块的支持还看不到希望。Notion 的数据库功能，倒是看到一些插件朝这个方向努力。
现在的 obsidian 里，^ 和 [[^^ 命令的块引用很差吗？
肯定是不如 Logseq 来的灵活，Logseq 的块有层级关系，且能在引用的地方直接编辑。Obsidian 目前不行（貌似有插件尝试实现，没具体用过。
我个人对块引用诉求不强，我一般会尽量把笔记原子化。即使是长篇笔记，到标题引用一般也够用。