这个回复很客观，简而言之，立场不同，考量不同。我是用户，想要什么可以提。我是开发者，要怎么做可以听用户的，也可以不听。自由选择而已，没啥对错之分。

这么说只是为了阐明需求，与具体做事的难度无关，我觉得你把我说的理解的太复杂了，所以有必要做一些简单的陈述。不代表所述需求实施的难易程度，不要想多了。

我都不想再辩了，如你所说，MD 文档是 MD 语法数据的载体，我只想用 MD 文档来存放 MD 文本，其他乱七八糟的格式，尤其是非明文的格式我不喜欢，仅此而已。

拜读了一下思源笔记缘起，上面所述的我基本赞同，因为二十年来我也确实在寻找一款可以长期使用的个人文档管理应用，也动过自己写一个的念头。但一是技术不到家，二是懒，所以一直在躺平。这一点上我是很佩服这些不服就干的人的。不过呢，哪怕遇见了思源也没完全满足我个人的需求。我也不想说什么代表广大用户的需求，至少二十多年来所经历的应用确实没有一个能完全满足的我个人需求的。或许我个人对文档的应用场景确实比一般人多一些，本来我也不想提这些的。因为就这些年在这行混的经验来说，很少有官方会为个别用户的需求而改变既定策略，各有各的想法，难免出现认知冲突，只是不吐又不快，我大概这辈子也很难自己去写个笔记应用，但有些东西说不说是一回事，听不听是另外一回事，如果有需求不说，那自然是我的问题。说出来有没人在意那不是我的事。所以基于此我在这里说了一下，并非指望官方就眼巴巴的赶紧给做出来，也只是让一些人知道有人有这些需求，有一些声音罢了。 至于说开源的问题，技术不到家，写写小插件还好，涉及到架构调整还是算了。官方给的源码没有说明，我至今都还没编译成功，更别提修改了。所以我改不了，即便改得了，官方也不一定接受。总之呢，思源的开源目前对于我等渣渣意义不大。否则我也不用在这里提这些“非主流”需求了。 最后，关于导出导入 MD 文档，我只是说它繁琐，不如直接保存 MD 来的实在，仅此而已。

己所欲就可施与人？那似乎叫独裁。干嘛非得加密呢？就喜欢明文存储不行？想加密的加密，不想加密的明文存就是了，给用户选择，而不是帮用户做决定。存在即合理是哲学问题，怎么说都可以是对，也可以是错，就不与你探讨了。做软件如做人，得道多助失道寡助，按自己的想法思路做事当然没问题，只是大多数人喜欢你只是因为同道，不喜欢你只是因为非同道。设限于小众，那便只能服务少数人。既然这软件只是为了服务那几个人，那我自然也没啥好说的。

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

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

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

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

首先明确目标是啥，思源的目标是啥？做个全能笔记？知识库？那当初为何选 MD 入手？成熟的笔记应用和知识库管理软件一堆，不和 MD 磕，去跟 oneNote、myBase 这些应用卷吗？感觉这种想法首先就是自我否定，然后迷茫。本末倒置了，搞那么复杂，其实有那么多需要吗？我只不过想要个全平台可用，用起来舒服，有简易文档分类的电子笔记本而已，甚至我都不需要什么双链引用和知识管理这些耗费精力的功能，这些功能从来只有极少数人用，大多数人并不需要，为了满足少数人的需求而忽略大多数人的需求，这路子似乎不怎么正啊。用产品的话说，很多东西看似重要，其实都是伪需求。

我说的这个并非需要扩展语法，只是找到一个不需要影响 MD 语法标准的写法作为 ID 标记。资源问题本身就不是问题，为什么非要把图片、视频、软件等其他资源合并到文档里呢？这本身就不科学好吧，只要刻意自定义资源存储路径，没人会在意这个。另外，再复杂的应用场景有数据库的支持还不能适应？那根本就不是 MD 语法的问题，那是整个数据应用的问题了。

当然，要说 md 文档没有内容块的说法，这个确实是，但没有办法解决吗？当然不是，要从 MD 文档反解析数据结构为内容块，那直接定义一套规则即可，既然思源已经将#号作为划分内容块的标记，那么按照这个规则拆分文档内容存储内容块即可，多级嵌套可以理解为多级集合，较为麻烦的是内容块 ID 标记，得找一个不影响 MD 文档展示的隐藏元素来存储内容块的唯一 ID，解决了这个问题，MD 文档作为主数据源自然不是事了。至于怎样解决，方法还是不止一种的，各有优劣，选择题罢了。

要满足思源的万物皆内容块，那么首先记录的最小粒度就是块，那么在存储数据上可以抽象为一个内容块就是一条记录，无论是用数据库还是 JSON 存储，以内容块作为存储单位即可。整个文档则由不同的内容块集合组成，具象化的话就是在文档表中存储包含的内容块 ID 即可，如此无论正向还是反向皆可查。解决了数据结构层面的问题，那么展现层的问题自然也不复杂，每个内容块都有单独的 ID，无论是内容定位还是类似列表的展示处理起来似乎都不算是事吧？

MD 本身确实不具备复杂应用的特性，但并不意味着需要放弃 MD 格式本身，无论是使用数据库还是 JSON 来存储 MD 源数据都可以实现复杂的应用，唯一要解决的就是与 MD 文件的关联，而不是彻底放弃 MD 格式。MD 是展示层的东西，也可以是源数据的载体，数据库或者 JSON 完全可以作为中转区域来实现各种复杂应用，没必要完全放弃 MD 格式，放弃 MD 格式也就是放弃了整个 MD 生态，以至于它就只是一个笔记，而无法适应更多的应用场景。比如 WEB 文档、移动端更好的写作体验、个人数据统一管理等等。