首先，这种设计是没问题的，为了支持复杂的应用场景，纯 MD 格式肯定是很难的，但哪怕是用到再复杂的数据结构，甚至直接用数据库也不妨碍同时生成一份 MD 文档，以及反解析 MD 文档为特定数据结构，如果是为了满足知识管理、块管理等，关联特定数据结构即可，没必要彻底放弃 MD 存储格式。

其次，所谓的唯一写入其实是伪需求，目的只是为了防止内容冲突不好合并，但如果笔记有协作需求，那思源目前来讲绝不是一个好的解决方案，除协作需求外可能产生写入冲突的地方应该是在第三方同步和其他软件直接修改 MD 文档上对吧？

这涉及到以特定数据结构为主数据还是 MD 文档本身为主数据的问题，用特定结构数据的话自然可以更加方便的管理数据，第三方软件对 MD 文件的写入对主数据并无影响，也就是说思源打开这个 MD 文档还是会恢复为主数据库存储的数据，但这显然有些违反直觉。因此以 MD 文档为主，特定结构数据为辅未尝不可。

结构数据的生成由 MD 决定，本身思源目前的原理也是这样，扫描 MD 文档的改动并重新建立结构数据用于各种辅助功能和查询，MD 文档作为主要数据生成的载体是可行的，因此不存在说无法实现思源目前的功能以及数据结构的问题，因为 MD 文档的普适性，决定了它的应用场景不仅仅是笔记，它是一个生态，比如市面上基于 MD 文档的各类管理系统，其数据源文件就是 MD 格式，比如在移动端一些写作体验较好的应用源文件格式也是 MD，在思源移动端体验依旧跟不上的情况下，使用第三方 MD 编辑器直接编辑 MD 文件也是最好的选择，另外第三方同步读写 MD 也比被思源锁定的特有格式有优势，唯一要解决的就是版本冲突合并罢了。就像代码协作提交前处理代码冲突，对代码进行合并，这并不是什么难事，这本身就是多端同步协作逻辑上肯定会发生的问题，不应为避免冲突而强制它不冲突，而是在冲突时给个解决方案，无论是强制覆盖，还是内容合并，或者是放弃更改，都应该是交给用户，而不是程序。

这是思源独占了文件···关了思源就可以同步了。实话说这个体验并不好···仅仅是为了满足思源自身的同步功能而不管是否在同步都强行占用文件，让其他同步软件没法读取文件。这是为自身同步和盈利考虑，毕竟要盈利才能支撑开源贡献。但矛盾也因此产生。思源不会刻意去支持第三方同步，相反，为了避免用户进行第三方同步，专门搞了个 sy 格式。不可否认，思源笔记很强大，也很好用，虽然目前 BUG 也不少，但不影响它成为一个成功的产品。如果想要自己把控数据，它却不是一个太好的选择，整个笔记解决方案里，可以把它当作编辑器和笔记显示器，存储同步方面还是得另想办法。