数据已经够大了，未来肯定要迁移到S3的模式。目前伺服党，还是希望思源本体的同步能足够快。

不过又要动同步这一块，现在好不容易稳定的同步逻辑，可能又要来点情况了。

支持体验优化，虽然不知道工作量如何，可能需要大量测试

可以探索下， 相互借鉴学习是优良美德😁

同样希望siyuan能同步快一些，手机app的使用场景基本上是闪念笔记，需要快速打开记录。

思源同步，我感觉最想让我吐槽的就是，明明可以通过元素活动和监听api来判断用户在干什么，修改了哪里，应该同步哪些修改，偏要扫盘，明明可以附件走另外的检索机制，偏要扫盘，明明可以根据操作按需同步，偏要扫盘，有一种被偷家偷多了不敢不全量扫盘的感觉，修改触发扫盘索引，扫完然后再一个个核对，我个人感觉明明是（操作文件）触发（指定的操作内容同步）更加高效，但是思源还是一股脑操作触发扫盘，然后索引，再一个个核对，思源明明每一步操作都有transactions，json本身就有很好的结构性，适合作为单个片段在网络中传输，但是在思源的同步机制里面，json结构貌似就只是为了方便富文本做更多的超文本标记，同步过程中完全没有结构化，只是根据文件切块而已，整个就是文件上传下载冷备份的逻辑，哪怕对象储存没有带宽上限，能做到千兆对等，性能也就这个样，思源的同步，并不关心你在做什么操作（不使用插件，只使用笔记本体功能），也不关心你的操作影响了什么内容，他不去看，也不去理解，他的同步并不携带这些信息，也不根据这些东西而触发，他只想在你写完了之后简单粗暴的扫盘，然后对比索引，这是一个非常省劲的操作，第三方同步这么干可以理解，官方同步，就给8个G，我真觉得有待优化重构，除非官方同步存在的意义就仅仅是，不用自己去买第三方对象存储，不用自己填参数，如果是这样的话，那确实没什么好说的

obsidian-livesync我也用过，它在本地做了监听，但不只是监听改动来判断该不该扫盘索引对比，而是准确的记录了改变了哪些内容，相当于通过插件补偿了（根据操作内容来触发指定内容同步）这个步骤，仅发送修改的操作内容就已经是最小的数据切片了，md并没有结构化，性能就可以做到这样，json本身有结构化，支持从整篇文章中解析出来更小的数据量进行同步，很可惜，目前json存在的最大意义还是储存超文本标记符和id，方便富文本渲染

1. listObjects 在对象多时很慢，比本地遍历文件系统慢得多
2. 考虑到本地文件系统可能会被外部修改，所以同步时需要遍历文件以确保一致性（文件系统监听方案跨平台会有问题）

这个 issue 我先关闭了，欢迎随时跟帖继续讨论。

1. listObjects 在对象多时很慢，比本地遍历文件系统慢得多

使用时间戳前缀进行过滤后再查找应该不会很慢吧，而且只是列出索引进行选择下载而已。考虑到livesync的效果，我认为它的性能尚在可接受范围内。

2. 考虑到本地文件系统可能会被外部修改，所以同步时需要遍历文件以确保一致性（文件系统监听方案跨平台会有问题）

这个确实，所以暂时还不考虑，不过我看有一些使用轮询进行监听的方案，我觉得后期可以看看。

进一步的研究见：https://ld246.com/article/1723703744376