今天 Logseq 提示有新版本，我顺手点了更新，结果应用启动之后整个界面卡得一塌糊涂，连光标移动都要卡顿半天。那一刻我突然有种被逼着做选择的感觉：我要不要继续用 Logseq？

后来我去翻了下官方的说明，发现这次更新的重点，是引入数据库版本，说是可以带来更好的性能和体验。可是，当我看到“数据库版本”这几个字的时候，心里其实是抗拒的——这完全违背了当初我选择 Logseq 的初心。

我是在 2022-02-07 开始用 Logseq 的，到现在差不多快四年了。这几年里，我把很多零碎的想法、读书笔记、工作记录、甚至一些琐碎的生活片段都塞进了这个工具里。最初被它吸引，是因为双链笔记的概念对我来说很新鲜，又正好种了 Notion 的草。只不过，我始终不太愿意把自己的内容交给一个完全托管的平台，所以才开始刻意寻找那种“本地运行 + 公共文件格式”的工具。

印象很深的是，我当初还兴致勃勃地向同事推荐过 Logseq。当时打动我的，并不只是双链，而是它默认的 Journals（日记）机制：每天自动生成一个以日期命名的页面，我只要打开就可以直接开始写，不用再为「今天这篇应该叫什么标题」而纠结。这个小设计在当时带给我的，是一种被理解的感觉——好像有个工具知道，我真正的痛点不是“缺一个好听的标题”，而是“我想尽快把脑子里的东西倒出来”。从这个角度说，Journals 的确满足了我很强的情绪价值，也因此成了我安利别人的重要理由之一。

Logseq 当时刚好踩中了我的所有要害：本地优先、使用普通的 Markdown 文件保存内容、不依赖专有数据库。对我来说，这意味着就算哪天我不用 Logseq 了，这些 .md 文件依然是独立存在的资产，可以被别的软件轻松读取，而不是被某个软件的私有格式“绑架”。不过现在回头看，像 Journals 这样的功能其实有很强的可替代性——无论是用别的笔记软件，还是简单用一个「按日期命名的 Markdown 文件夹」，都能实现类似的效果。它能成为我当初爱上 Logseq 的理由，却不足以成为我长期被它绑定的理由。

回过头来看，这几年里，我其实也逐渐意识到，双链和图谱这些看起来很酷的功能，对我个人的实际帮助远不如想象中那么大。刚开始那段时间，我确实很沉迷于给页面互相加链接，看着图谱一点点长大，会有种“知识在生长”的错觉。但随着时间推移，我发现自己真正会去用、会去回看的内容，更多还是那些结构清晰的记录和文章本身，而不是网状链接。

至于 Logseq 在 PDF 上的标注和各种高阶功能，说实话，对我来说需求频率很低。偶尔会觉得“有这些功能真不错”，但真的要说离不开，它们也完全称不上是刚需。

这次版本升级导致的卡顿，我通过还原旧版本暂时解决了问题，表面上看起来一切又恢复了正常。但在还原的那一刻，我心里很清楚：我对 Logseq 的信任，其实已经被动摇了。不是因为这一次小小的卡顿，而是因为它正在朝着一个我并不认同的方向演化——越来越重，越来越依赖数据库，离“纯文本、可迁移”的初衷越来越远。

更现实的一点是，我到现在都还没有找到一个完全满意的替代品。很多工具要么是纯在线的，要么是功能过于庞杂，要么是数据格式不够开放。于是我就卡在一个尴尬的中间状态：继续用 Logseq，总觉得随时会有下一次“灾难性升级”；立刻迁移，又不知道要迁去哪里，也没有足够的时间和精力去折腾新工具。

所以，“准备弃用 Logseq”对现在的我来说，更像是一个心态上的转折点：我不再把它当作那个“可以长期托付笔记的唯一选择”，而是把它当作一个“目前还在使用，但随时可能被替换的工具”。这也意味着，接下来的记录方式、文件组织、同步策略，我都要尽量往“随时可以迁移”的方向去调整。

也许未来我会找到一个更合适的笔记系统，也许最后我会回到最朴素的目录 + Markdown 的组合。无论怎样，我越来越清楚一件事：工具只是辅助，真正重要的是我如何思考、如何记录、如何与这些内容保持长期的关系。而一旦某个工具开始违背我最在意的原则，我就该认真考虑和它划清界限，而不是被动地跟着它一路走下去。

现在，我还在用 Logseq，但我已经开始为离开它做准备了。