解析 json 自动完成合并操作是不现实的，因为这实际上是树的合并，类比到代码中就是生成 ast-patch，你可以看看有哪个软件实现了这个功能。

或者说，假如发生了文件修改冲突，git 目前的合并机制能保证最后生成的是一个合法的代码文件吗？以我的经验来说，是不能的。

代码文件的格式合法化要求还低于 json 呢。

感觉你并没有理解我的意思，无论怎么说思源在同步笔记数据上都是 git 的加强版。建议可以自行使用 git init 一下尝试效果。

对同一个大文件反复修改，应该不是常态吧

我不了解为啥要突出大文件，实际上无论大小，多端同一个文件修改就是造成冲突的问题。

只要还有同步机制，都要做文件合并机制

嗯，确实，那是否有看到什么富文本、xml、json 合并的良好方案？目前大概只有纯文本的合并比较好做吧。任何想要离线完成合并操作的，都无法绕过这个问题。在线可以直接云端协调，确保实际上只有一个文件在修改。

siyuan 的同步模式就是近似于 git 的 push、pull、merge，客户端、历史记录都有，问题是思源的文件不是这么好合并的……想的简单了点。

另外，思源需要实现同步量最小，git 的全量模式会同步到你脸皮发麻的。

错误的，思源就是使用时间机制的，但是很敏感，边界问题很多。举个例子来说，思源正在同步文件回来，这时候你打开了这个文件，光标移动，好，修改了！这下就判定你这个文件更新日期更前了。

还有一种情况，思源为了使用修改时间进行判断，他会同步过来后修改文件的修改时间以跟快照匹配。举个例子来说，你的文件修改时间是 2024.10.14，10.15 同步到手机上，那实际上你手机上被同步过去的文件修改时间是 10.15。所以思源需要修改这个时间为 10.14，但鬼知道什么原因，这个 api 有时候工作不正常。然后就会判定为更新，进行同步，快照实际内容没有变，但是快照对比一片红，因为 id 变了……

反正使用更新时间作为判断依据就是现在采用的，但是边界问题确实挺多的。

其实我很久之前就建议利用 codemirror 替代代码块，还有这个部分了 😋 不过最后还是看到作为插件形式出现了

关于锁的问题，我其实觉得锁的问题并不是 s3 或者说非中心服务器同步的问题，而是思源独有的问题。因为思源要达成一个在其他备份软件都根本没有考虑到的问题：只下载需要的、最新的快照。

两个要求共同导致了这种复杂局面：

第一个导致了思源不能把全部快照全下载下来，这样就不用考虑锁的问题。

第二个要求导致思源必须要有某种手段得知当前最新的快照是哪一个。

那很自然的方法是加个元文件，然后围绕这个元文件的读写就变成复杂的并发加锁问题，而且哪怕你的实现毫无问题，一个 s3 cdn 就能让你的设计沦为空谈。

那有没有绕过的方案呢？其实也是有的，除了每次都下载全部索引，然后挨个确认哪个是最新的，其实一个最简单的方案就是在索引的名称上下功夫，在索引的命名上加入时间戳和 hash 信息，然后想办法获取索引的列表，这样就能在不下载索引的情况下获取最新的索引是那一个了。

但是这有个新的问题：列出的索引太多怎么办？本地处理肯定没有问题，但云端问题很大，s3 是有最大列出数量限制的，而且数量大了响应也很慢。

我想出来的处理方案有两个：削减索引的数量，只列出需要的索引。

我只要保留需要用的索引，那么索引的数量是可以很小的，全部列出来都不会造成很大压力。比如可以按照 restic 的这种方案保留：保留最近的 30 个快照，1 个星期内每天 3 个，3 个月内每天一个，1 年内每周一个，等等。这样能在保证快照可用的情况下，极大削减快照数量，得以保证列出速度。

不过这个已经 over 了，第一步想要增加删除指定快照能力的 pr 已经被否了。目前来说，下一步也不用考虑了。

第二个就是只列出指定的索引。s3 是有前缀搜索的 api 的，因此我们只需要把索引的命名中时间戳放在前面，然后比对上一次上传快照的时间戳与当前时间戳的相同部分作为前缀，就能轻松的找到这段时间中云端更新的快照。

然后这个也 over 了，原因是思源还有 webdav 的支持。webdav 不支持前缀搜索，只支持列出文件夹。要实现类似 s3 前缀搜索的效果，就要修改索引的文件夹结构，把时间戳的一部分作为文件夹，然后列出对应的文件夹。考虑到目前官方对于同步机制的保守意见，我不认为这个 pr 能通过。

但其实抽象来看，官方的保守态度，其实正是这种情况的具象化：任何对同步的改进都必须面对对当前同步同步效果满意并且不希望有任何不稳定性的用户，而鉴于同步问题的复杂性，在大多数情况下这个问题的答案都是 no。

综上所述，大抵思源的同步机制在现有情况下，确实没法做到更好了。

微信读书加第三方工具导出？emmm，谨防封号，思源原本也有一个微信读书导出插件，后来有用户封号了，为了防止出现类似情况下架了。虽然插件还是能继续用……

未做前端大纲优化，大纲本身就没有动态加载机制，一次加载 19000 个目录项卡了很正常。

嘶，感觉也不是不行，回头问问萌佬？严重需要 bug 测试员

不过，加入闪卡的话，大概不只后端的 golang，前端的 electron 都要留下血泪了，我记得闪卡是默认全文加载的……

建议多等一会，多滚动一下，看看会不会爆内存 😋

嘛，去看看不就知道了，反正我觉得是简单的，但是对于大部分人使用的 1m 以下文档也就 10ms 左右的延迟，真的有必要吗……

那首先需要有大量勇于尝试的小白鼠用户， 因为我自己都不能确定哪里可能出问题。

况且认真来说，真的会有人疯狂到往笔记软件塞一个 wiki 百科吗？只要不是这种情况，思源对于 10mb 以下的文件还是毫无压力的（400ms 的加载和编辑延迟）。

只能说 golang 的性能还是太好了，这种写法都感觉不到性能压力，隔壁的 logseq 和 obsidian 都已经流下血泪了……

为人类心智服务的良好工具，简单而纯粹。

打回重做阶段。

下游还没做完呢，上游算法就更新了。

叶佬最近好像还想搞短期复习时间的规划，虽然很期待，但不得不得说还是麻了。

我觉得这没啥问题吧，思源功能多一点和思源没有大家都没有的功能并不冲突吧。不然你说思源什么功能都没有或其他软件没有的思源都做了才是不符合实际的。

思源自己不能，或许插件可以。

这可能是在同步，第一次全量上传很耗时的。

思源并不适合记这种类型的笔记，你需要使用带有白板支持的笔记软件，或者你需要修改自己记笔记的方式。

比如说写成：

The designer pushed him by design,making him annoyed
designer: 主
pushed:谓
him:宾
by:介
making:动词+ing

你要学会把图形信息转变为顺序结构，要不你就只能自学 html 块硬写了。

我认为功能迭代快是因为功能少所以爆改不用担心 bug 循环，意见反馈迅速是用户少还可以挨个看一遍并且不用担心用户需求冲突。

客观来说只要功能数量和用户体量达到思源这个量级甚至更少一点，那迭代和反馈的表现总是差不多的，毕竟人力有限，这个开发者还更少，目前只有一人。

来自 tiddlywiki 的奇怪方案。

看看 D:/科研/book/SiYuan 的截图？你这看上去是把笔记塞在安装目录下的效果啊

很简单，刷新一下思源就行了。

建议使用插件 开发者工具 的重载窗口功能。

F 佬这一波操作是直接达成我想实现的效果了

尝试减少输入字符，并使用空格分隔，如“风 华 公 交”

需要传递搜索结果给思源，那就有点难写了。

为知能解决问题，那就挺好的呗。

感觉可以建议一下官方，在订阅用户使用自定义 s3 的时候也能使用官方的同步感知。

@88250

去看看正儿八经的开源多维表格吧，apitable、nocodb 之类的。

简单节点参考 思源大纲笔记模式的性能测试

已知 bug，上一次的搜索结果没完全清除，可以输入空格强制刷新