昵称没什么用，随便写都行

说实话，还是有些难过的

如果说开发时间太长，开发资源耗费过大，有些点比较麻烦，需要时间，都会表示十分理解，也不是不能等

甚至列到长期开发计划，也好有个期盼

还是希望对这个事情再慎重考虑以下的

甚至换个思路，换种形式，曲线拯救下都未尝不可，还是那句话时间不是问题

突然想到个点，能否把历史记录当个单独索引的内部笔记本呢？这样的话

• 解决可以搜索的问题
• 同一文档的不同版本在子文件夹下，用时间戳进行区分
• 可以用所见即所得的形式展示
• 全加载，不用分页，像笔记本一样展开

我之前也是这样啊

所以我现在反思

体谅开发者的辛苦，自己总结“非正常使用”经验，防止数据被覆盖，被丢失

在付费云服务情况下，自己研究文件同步，给自己数据安全加码

出了很多次问题发帖，明明很气愤，语气却“温和而中庸”甚至带着些许调侃

错误的将一些“性命攸关”的严重问题，让人误以为“不痛不痒”

我不同意这个看法

有点“斯德哥尔摩综合征”了，遗憾是我之前就是这样

我之前已经发过好几个帖子反应文件恢复的问题，为何直到今天问题爆成这样，才改善？

在我好多次丢失文件，发帖反馈，并没有明显改进措施的情况下，依然“同理心”泛滥，抑制自己真实的情感表达

所以或多或少“间接”导致“惨剧”延续到楼主的使用中

再“若批评不自由，则赞美无意义”

另外，送楼主一张图，可以抒发下情感

历史记录的数目不够，体验不好，及其容易出现“无法恢复数据”的情况

找不到两天前的历史记录

记一次数据恢复的“一地鸡毛”

丢文档了，问题很严重，现在头很大，日后该怎么用有些迷茫

我也经历过几次了，点进我的主页，看我的发帖记录，用 VS Code 打开 history 或许还能有一线生机

功能改进，提示升级，这不应该是正常功能吗

D 的意思基本就是“同一时间只能有一台设备在线同步”

文件损坏的话，我建议是保留并提示

甚至给个警告的图标，但直接删掉的话，是十分不妥的

历史记录的数目不够，体验不好，及其容易出现“无法恢复数据”的情况

看看我的血泪教训，用 VS Code 试试吧

如果本地历史记录还在的话

快照不能细致恢复

历史记录不分页

对于时间久了文档的恢复，问题很大

再就是当前触发显示的面积是整个“文档树”区域

而不是上面的一小条，问题不大的

所以，我依旧支持隐藏的

这个功能我之前提过加快捷键的需求

已经实现了，我现在用的，也是推荐的用 Alt + F1

默认没有，在快捷键设置里面有的

所以我投了“支持隐藏”

要说先进呢直接存数据库就好，何必瞎折腾存什么物理文档。既然存在，那必然是有道理的。存数据库是方便，但跨平台同步怎么办？数据库的合并可不像文档合并那么简单，离线同步也不可能用中心化的数据库来处理，否则网络不通冲突依然存在，当然，解决方案很多，想要解决你的先进数据存储问题有很多优秀的方案可用。但为啥非得存 MD 文件？因为有地方要用啊，具体怎么用你也不用问，总之是有这个需求，无论是对接第三方系统还是个人笔记管理，都有其存在的必要性。导出固然也可以，但费事。简而言之就是想偷懒，编辑完就完了多好，还得导出解压放到指定位置去，这就增加了使用成本，因此我提这个也仅是基于使用不便来提，然后延伸出一堆问题，说了那么多我也不想再说了。思源要做成啥样我管不着，就提点看法。有无道理两说，总之我的需求只是好好管理我的 MD 文档，而不是管理所谓的知识或是笔记。这些在 MD 文档里就包含了，不需要软件替我思考该怎么管理内容，然后强制我按照这种思路去管理我的内容，即便这种方法确实很先进，但也意味着繁复，结果未必高效。

作者：shileiye
链接： 关于思源笔记的一些看法
来源：链滴
协议：CC BY-SA 4.0 https://creativecommons.org/licenses/by-sa/4.0/

思源是有数据库的，“重建索引”只得就是数据库

有物理文档，是为了和数据库形成优势互补，物理文件偏重于个人备份，数据库偏重于检索功能

并不是什么事都“存在即道理”，新冠还传播着，有道理吗？非洲还有饿死的人，有道理吗？

多看看官方帮助文档就会知道，思源跨平台同步用的是加密后的文本就行同步的，跟数据库没关系

不需要软件替我思考该怎么管理内容，然后强制我按照这种思路去管理我的内容，即便这种方法确实很先进，但也意味着繁复，结果未必高效。

“己所不欲勿施于人”

如果思源不是基于 MD 我可能用都不会用，用思源本质上就是基于 MD 写作，思源要另立标准那也无所谓，再找另外的 MD 编辑器就是。是的，目前来说我只是把思源当作 MD 编辑器在使用，用它做知识管理是有风险的，不是诅咒哈，但我从不相信有啥万年不腐的软件，假使有一天思源不再更新了，那么思源独有的数据格式迁移起来就麻烦了，最明确的文件夹 + 文件本体的物理存放 MD 文档是最稳妥的方式，思源的逻辑分类实话说迁移起来比较费事，文档结构里每个分类都一个多余的 MD 文档不说，批量导出也不含资源，只能一个大分类一个大分类的导出，确实麻烦，不是我对思源没信心，只是见惯了跑路和毁前途的软件，用之前都得考虑好结局，这是底线，也是不想受制的考量。你可以说我格局小，但真不想也不愿在一棵树上吊死。

作者：shileiye
链接： 关于思源笔记的一些看法
来源：链滴
协议：CC BY-SA 4.0 https://creativecommons.org/licenses/by-sa/4.0/

思源没有另立“标准”，内部封装形式本质就和用户所解耦的，就是用火星文写也没关系

在用户侧来说就是“MD 语法写，MD 文件导入，MD 语法导出”

凡是都是有风险的，我理解楼主的担忧，但有句话是这样说的“不谈计量谈毒性，都是耍流氓”

引申到这里，显然就是：不量化风险大小就说风险是不够严谨和轻佻的

此处思源的核心优势就是“开源”了，相信楼主肯定会在仔细读过楼上已经有别的朋友评论过的

哦对，再提一嘴什么是开源。

开源就是这些源码是公布的，有效的，所有人都可以看、下载、修改和编译的，你自己可以在约定的规则下编译、修改和使用的。

那么之所以 D 大和 V 大哪怕把项目删了，都无所谓，就是代码是完全公开的，这个项目不是像 QQ、WX、Word、WPS 那种私有的，代码完全不公开，这几个公司没了这软件就不能用的。而 Siyuan 你完全可以自己编译，或者用 Github 编译，都是你的自由。你也可以感觉 Siyuan 那里写的不好，不随你的心意，只要 Fork 一下，你就有一份随便你使用的 Siyuan 代码，随便改。

Siyuan 自带的同步是官方同步，但这个文件夹就在我本地，我随时都可以访问，明文存储，我想备份到哪都可以，我就是直接备份到我的 Github 私有项目。我这两年都来来回回重装十几次系统了，Linux、Windows、MacOS 都用过，Linux 发行版我都用过五六个，要么直接复制粘贴，要么直接 git pull 一下，都没有一点影响 Siyuan。

所以，支持开源，相信开源。

作者：GuangDai
链接： 关于思源笔记的一些看法 - GuangDai 的回帖
来源：链滴
协议：CC BY-SA 4.0 https://creativecommons.org/licenses/by-sa/4.0/

以及再自行细心搜索“开源意味着什么”后

真正的理解“使用思源的风险到底有多低”

要是还不理解的话，楼主可以去把 D 的帖子搜出来，看看

算了，我人好，怕楼主麻烦，已经找到了 思源笔记缘起 - 链滴

数据可以完全离线以后，还剩下最后一个问题：软件生命周期。

没有任何软件开发团队能保证软件能够持续可用，从开发团队来说，发生软件终止维护的可能性太多了，比如：经费不足、研发目标转移或者遇到不可抗力（比如开发人员突然离世）。

有一种有效的方法可以在最大限度上解决软件停更造成的不可迁移，那就是 开源 。如果软件有足够价值且是完整开源的，即使主创团队无法继续维护了，其他开发者也能接过重任。从开发团队实际情况出发，完全开源是比较难办到的，虽然开源商业化模式在很多项目上已经大获成功，但并不是每一个项目都适合这样做或者说需要等待适合的时机。

作者：88250
链接： 思源笔记缘起
来源：链滴
协议：CC BY-SA 4.0 https://creativecommons.org/licenses/by-sa/4.0/

虽然看完这篇“缘起”的帖子相信楼主已经可以进一步理解思源的部分情况

但还是说以下万一地球毁灭，没人接手思源，应该怎么办吧

1. 不要折腾思源的 .sy 源文件
2. 直接导出 MD 文件包
3. 找到支持 MD 导入的软件，导入

要是还不行的话，思源的数据解析器也是开源的，楼主“不过是”改改解析器 .sy 文件想怎么导出就怎么导出，什么 Word，富文本，自己开发套笔记都可以

有人说“历史虽然不重复，但总是压着相同的韵脚”

但也有人说“历史数据不能代表未来走势”

文档结构里每个分类都一个多余的 MD 文档不说，批量导出也不含资源，只能一个大分类一个大分类的导出

我刚才试了，通过软件导出 Markdown 的形式都是可以的，所以我并不清楚楼主为什么这么说，我不相信楼主不自己试试就冒出来这句话，应该是我理解有误吧，希望楼主有时间的话可以进一步描述这个场景的不合理之处

只要言之有理，我就带头提开发需求，再不行就在社区开投票贴，再不行就磨开发者，直到满足需求为止，这当然不是说服楼主转投思源，毕竟这是个开放的社区，您的建议或许可以方便的更多的用户

说到这里，希望楼主用的不是 ob ,毕竟 ob 连开源软件都不是，从这个角度来说 ob 很有可能就死在思源前面了，谈何“超越”呢

所谓生态就是围绕一个关键因素建立的应用关联，你只看到了笔记一个场景，却忽略了整个大环境，目前 MD 文档正在成为富文本外的第二选择，许多应用系统集成了 MD 文档的直接应用，比如一些博客系统、一些文档管理系统、一些办公系统、一些信息发布系统、一些阅读系统、一些 IDE 开发工具等等，更不用说让 MD 源远流长的 Git 代码库了。你想到的只是满足个人写笔记，却没看到那些 MD 正在肆虐的地方，符合标准的 MD 文档正在成为主流。而原因，正是因为它的简洁与复杂，不矛盾，用简洁的语法实现复杂的效果，这就是 MD 的魅力，而你居然把它的优势看成一种劣势，着实有些以己度人。论复杂，请问你为啥不用富文本、HTML 写笔记？

作者：shileiye
链接： 关于思源笔记的一些看法
来源：链滴
协议：CC BY-SA 4.0 https://creativecommons.org/licenses/by-sa/4.0/

“MD 语法”和 “MD 文档”并不能相提并论

我相信 “MD 语法”正在成为富文本外的第二选择

不认可“MD 文档”正在成为…

“MD 肆虐的地方”与思源可以完美融入，因为开发者本身就是 MD 开发专家，支持最标准的 MD 规范

在就像之前已经说过的，MD 简洁是排版的魅力，不是知识管理的魅力

在知识管理和笔记软件的角度来看 MD 就是一种劣势

“论复杂度”并不代表“MD 简单不能用，json 复杂而可以用”，意思是“当前知识管理的场景下，MD 简单到不能用”

诉求不过是另外自动保存一份 MD 文档，而非导出。其他问题不过是这个问题延伸出来的一些可以解决的问题。

这个诉求的本质就基本等于“不可解”的，不能用一种类似“世上无绝对”的逻辑，假设时间无限，开发资源无限的前提，来说这事是可以做的。即使在可见范围内，这个问题都不可解，不可解的原因在之前已经罗列过了

这句话用了两个“不过是…”，这是一种十分轻佻的表达形式，虽然相信楼主本意可能并非如此，但依旧像之前已经指出过的“理解不了这件事件背后的复杂性”一样的问题

以下是我个人主观认为

Markdown 是就是排版为主的，用 Markdown 做存储的只是在笔记软件探索阶段的一种阶段性尝试，ob 等软件的继续沿用，更多是一种“路径依赖”，既然是路径以来，就不能说明 Markdown 做存储的先进性

我觉得评价思源不完美，有缺陷，自己不喜欢…的原因都可以

但如果用 Markdown 的前提来诉说，我个人观点就是“格局小了”

（无意冒犯，敬请见谅）

我对 “md 笔记生态”一说存疑

只是有很多软件支持 md 语法，尤其是笔记软件

再就是说的上的 md 笔记软件也就 ob 和 logseq，而且现在这俩的 md 文件很容易不兼容了

这已经有悖于 md 的初衷了

对了，如果说“md 笔记生态”是支持 md 语法的，那思源是属于的

如果“md 笔记生态”是用 md 文件存储的，那我觉得及没必要，也弊端显著，不进去挺好

再就是回应一个问题

思源基本就是文中说的“MD 做展示，而后端用独立文件格式”的形式

甚至 MD 文件在思源可以实现自由的导入和导出

说点“感情用事”的观点：

1. 在已经有了 ob logseq 等用 MD 做格式的笔记软件后，思源没必要进去内卷了
2. 在日益复杂的功能场景下，MD 格式的局限性只会越来越大，额外消耗开发资源

不同意各有优劣的说法，MD 的弊端更大一些。

而且楼上已经有朋友引用了 D 的帖子，里面说的也很明白

1. 扩展语法的路走不通
2. 就算扩展语法也无法解决 MD 资源文件问题
3. 无法应对未来更加复杂的场景

一个核心问题：如何在 MD 文件中唯一定位到一个块

如果是为了满足知识管理、块管理等，关联特定数据结构即可

具体如何关联特定数据结构，可以了聊聊大致方案吗，我看这是之前 MD 做知识管理一个很重要的问题，用“…即可”无法体现出解决这个问题背后的复杂性

对于 Markdown 的不合适用于知识管理有以下几点

1. 知识管理需要对一段知识，或者一个块进行唯一标记，但在 Markdown 设计之初就没有这样的需求，所以 ob 在这一块实现的既不优雅，也不够实用，块的定位有问题
2. Markdown 文件无法保证文件的唯一写入，这就会造成文件损坏，权限异常等无法解决的问题，解决的办法只用思源通过 api 才能对文件保证“事务性”的操作

Markdown 主要是用于排版的，承载不了知识管理的重任 - 读 D 宝 语录有感

很麻烦的，操作复杂到非专业用户几乎恢复不了，想看操作方式的话，可以看我近期发的

历史记录的数目不够，体验不好，及其容易出现“无法恢复数据”的情况 - 链滴

给每个文档一个 version 值，是否可以应对这个情况

在思源中“文档”和“文件夹”在使用上是没有明显区别的