logseq 还不错，至少我用过那么多笔记软件后现在安稳地使用 logseq 并每月捐款 
我现在对笔记 (note-taking) 的看法是，先找一个过得去的工具动起来，把这个工具用成自己的形状；记笔记的方法也是，先记笔记，看自己实际使用了怎样的方法，看怎样的方法更符合自己的需求。这样，对工具和方法的改进和追求或许就更多地受解决具体问题的需求驱动。这观点和你提到的 “先做起来，而不是等工具齐备 / 没有绝对完美的工具” 基本一致，但多少更激进 (?) 更强调实践。
诚然，利用好的工具和好的方法来做事很重要，但或许现在普通的工具和方法已经够好了。研究写笔记这件事确实能给人一种 “在干正事” 的感觉，但我现在觉得我之前是在逃避真正干正事的痛苦 XD，我现在觉得我应该真正把时间花在正事上。
1 个赞
logseq我曾经遇到丢数据的情况，很可怕，不敢再用了
引一句别人的话
我不敢用 logseq 的主要原因是
遇到冲突 它的默认机制一般都是 删除而不是备份……
这种体验太刺激了 对我来说
的确是一个问题。不过 Joplin 自身一来提供了不少 API，二来最坏情况下也能从其用户目录下的 SQLite 数据库中恢复信息，所以还是相对安全的。
Joplin 自带笔记历史功能。（设置 - 笔记历史）
看到了组织模式，还是有点喜欢的。
但是，怎么说呢，唔，我不信任任何平台和软件的长久性，这应该可以理解吧，毕竟我也曾一次次的把某个平台/软件视为最好选择。所以我更愿意去相信简单通用的格式。
我听希望有快速的笔记链接、笔记引用、笔记块这类功能的，但是，这些功能很可能造成未来与某些平台难以兼容，导入困难。
总之，简单可靠，这样未来可能需要的投入才最少。（加粗不是大声讲话，只是标记一下，方便我自己回顾
做这件事情已经在做了，否则也不会有已有笔记需要整理。只是不够系统，或者原有系统不够完善。现在主要是在方法论上实现统一。算是一种长远的系统上的规划。
软件这个，单纯自己强迫症。不信任任何平台和软件—>未来必然会迁移—>更重视格式上的问题—>不敢随便引入各种酷炫功能。
我用过的每一款有同步功能的笔记都弄丢过我的笔记，所以，注重多地多版本备份十分重要。
同时因为一次的数据丢失就否认一个软件，也许没必要（毕竟都……这样吧
今天同步错误，给我删的个干干净净，就剩下两个我新建的目录（摔
不止一次，也不止我一个人，可以去他们的论坛看看
再说我也仅限本地使用，根本没有云端同步
logseq的工作数据是保存在浏览器（或者electron）的缓存里，定期和文件同步的，这个同步过程常常会出一些问题，冲突是在这个时候发生的，他们还专门有重新扫描磁盘文件的按钮
除了丢数据之外，还有文档格式不标准（md+org混合）的问题
不仅笔记文件会冲突，配置也会冲突，有时候会遇到保存配置重启后不生效的情况
我也是，所以在捐钱，希望它能活得稍微久一点
除了不相信软件和平台的长久性，我也不相信当前笔记价值的长久性。我觉得我现在写的笔记在之后 (比如说十年后) 只有当日记看的价值 (还比普通日记枯燥)。如果十年后我还对现在做笔记的内容感兴趣，而且还觉得现在当笔记记下的东西有很大价值，那我进展也太缓慢了 XD 所以只要笔记软件以纯文本 (或其他易读取的形式) 在本地储存我就满足了。
2 个赞
个人觉得Obsidian是很好上手的，只是网上的教程看起来太「高大上」了容易吓人。
我的Obsidian就用的很简单
logseq更简单一些
我的Obsidian本地文件结构
十分赞同！
（双向链接不好读，所以尽量舍弃，2333
我用过一段时间的 joplin ，是在我决定放弃 yu writer 之后，它在我使用期间的主要问题是同步，当时我还没有想到可以用 onedrive 在外部同步，直接使用它内置的同步方案，遇到了超多的问题（主要的锅就是历史版本记录导致单文件过大）。
目前我使用 Obsidian 但实际上就是拿它当作 markdown 编辑器在使用啦，大部分功能都没有用到。
最近我发现双向链接的作用比我之前想得更大，比如它可以把页面当标签用。logseq 支持以 [[]] 创建页面，也支持以 # 创建页面。所以我把我创建的一部分页面当标签用，有时随手在某段笔记后面加个 #blog 或 #支出 之类的，这样在 blog 或 支出 页面就可以看到所有添加了对应标签的笔记块。
至于双向链接 “创建知识节点之间的联系” 之类的作用，我还没体会到
我在用吖，用它搞定从本机到 NAS 这一步，今天它就翻车给我看，2333
这个是 Wiki 的功能，所以我真的很想转向 Wiki 系统，但是还没遇到让我觉得很踏实的方案。
我是习惯在元数据里添加标签，毕竟井号和原生 markdown 语法有点歧义了。
被小老虎启发了，想想把同步的文件纳入 git 也行，反正我服务器里跑着一个每天定时提交的脚本……这样直接就有版本管理了。
Obsidian是纯本地文件（我也懒得搞图床，图片直接放在笔记库中）
配合git和obsidian-git插件，就能定期commit和push了
而且Obsidian可以一边「先记起来」一边根据自己需求去调整功能（甚至用着不爽直接卸了换软件都行）
多余的功能不需要也可以直接关闭，当编辑器使用
很符合楼主提到的要点
在已有页面创建新页面好像是在互联网诞生之前就存在的概念和想法 (翻了一下一时没找到出处)
logseq 里 markdown 味不是很重，毕竟第一眼看起来它就是和 workflowy / 幕布类似的大纲式笔记，所以好像 logseq 里不支持 markdown 的标题语法 (好像也不需要)。
另外，在 logseq 这样的大纲式笔记工具里插标签和 Tiddlywiki 或 纯文本文件的元数据区插标签的一个区别在于精度。后者的标签先与整个文档关联，但前者的标签先与具体笔记块关联。不过这不是很重要
我被你说动心了怎么办，然后就安装了一个（赞美 Scoop，真方便
然后打开上午导出的 md 内容，无缝打开，舒适了！文档间链接直接使用文件名（相对地址？）可读性挺不错的。
我意识到一个问题：代码编辑器我喜欢深色的，而笔记软件我喜欢浅色的，并且笔记软件界面排版不可以密集，看起来挺无足轻重的细节，严重的在影响着我的选择。（我知道，我已经切换成浅色模式了，23333
有点小问题，这种基于文件的就很容易没有元数据，这篇笔记什么时候创建的，什么时候修改的，标签啥的……
对的，这种需求就需要配合插件了，对于元数据，需要Quickadd+template+Dataview
另外，由于Obsidian是纯本地文件，一个文件夹可以套好几个软件，比如git、vs code、logseq、obsidian共用一个文件夹（笔记库）
Obsidian 自己只支持两个元数据：aliases、tags
其他的需要自己按需设定了
（只能使用这种在文本内yaml的形式来实现元数据）
1 个赞
终究是引入了更高的复杂度……
也下载了 logseq，组织模式，以及方方面面看起来都很 wiki。很赞！（虽然我转到它上面的成本会比较高，不过这个先不考虑）
依然是平台忧虑，如果这个软件倒下了，是不是说目前没有能够很好兼容这一套格式的其他软件。
是纯文本，笔记间链接使用 [[格式]] 是具有较强可读性的，但，块引用就……((5f713e91-8a3c-4b04-a33a-c39482428e2d))
一个问题：似乎没有简单，通用，具有很好可读性的块引用方式，当然可以自己规定，然后就要自己去弄对应的阅读器。选用这些现成的解决方案也是类似的情况。
对的，那个用YAML实现元数据的方法是我一开始照着教程弄的（有点小复杂，不过弄一次就行）
但是我越用越简单了，我的第二个笔记库就没搞这些插件
放弃使用其他的元数据，只用了tags，因为我在Obsidian中只记永久笔记了
就记笔记的习惯，我的Obsidian笔记库中只有Notes，inbox在另一个软件中，因为：
- 用Obsidian实现inbox又要小折腾一下
- 我对inbox有跨平台、快捷的需求（Obsidian用git跨平台不够快捷，移动端需要手动pull和push）
- 所以觉得把inbox分给其他软件很舒适，Obsidian用起来还是偏「正式」一点，而inbox可以随意一点
Obsidian就是什么需求都能实现一下，就像拼积木一样，但是很折腾
不过这也是我喜欢Obsidian的原因，它让我这个不会编程的人见识并接触到了很多偏底层的东西，并产生了兴趣，而不是单纯地用平台发布的软件