D

如果同步需要的时间大于 30s，则永远无法完成同步

不会的，如果某次同步超过 30s 并且期间发生了数据变动再次触发同步（或者手动同步），那么触发的这次同步会被放弃，因为上一次同步还未完成。

实际上现在就是这样的，启动阶段不会真正进行数据交换，只是对比索引，然后决定要锁住哪些文档以避免本地修改和云端造成冲突。

前面我已经说了，启动慢主要是就是因为要加载最新本地快照，加载以后才能对比索引，加载快照时读取文件对象慢是目前的瓶颈。

• 这种场景建议用收集箱
• 最后看的那个笔记也可能需要同步（从云端下载更新），但是不同步之前是无法判断要不要预加载的，这是一个鸡蛋问题

对了，刚刚我说的移动端用最后一个快照的想法实际上也不会有多大提升……因为慢是慢在加载本地快照（就是界面上出现“正在索引数据仓库，获取最新文件...”），而不是慢在下载索引或者对比差异等，这些在库较大时耗时其实不高，主要就是加载快照比较耗时，因为要读取本地仓库最新快照中的所有文件对象。

这个点我们得再看看是否还有优化空间，如果代码实现上优化空间不大的话可能就要考虑下用其他结构来辅助一下，总之，我觉得还是有希望提升突破一下的。

那数据就无法保证一致性了，快照要保证的一点就是一致性，如果云端覆盖本地时再去判断就晚了，这个时候数据很可能已经变动。

不纳入快照的话没有差异，不会生成冲突历史的，相当于正常云端覆盖本地。

不索引的话会有问题的，相当于外部改动不进快照，如果云端更新了这种情况就无法判断覆盖方向了，只能云端覆盖本地，并且不会生成冲突历史。

移动端上可能可以考虑用最后一个快照，因为移动端上不存在外部更新的情况。

是的，思源账号就是链滴账号

没有哦，只有积分奖励。

不行的，资源文件很可能会变动，比如外部修改 Word 文件。

差分同步

不太可行，因为不进行对比的话是不知道最近修改了哪些文件的，对比放在启动时就是为了加快整个进度，避免进入界面后还要等待太久。

可以等下个版本 v3.1.14 再试试，我们做了一些优化 Issue #13216 · siyuan-note/siyuan

• 并行 数仓索引 和 下载云端快照索引 这两个过程来降低启动时间，在固态盘上测试 1W 个文件且网络良好的情况下大致可以比之前节省 1/3 的启动时间，3K 个文件的情况下大致节省 1/2 的启动时间
• 数仓索引 时使用更高效的遍历函数 filepath.WalkDir 替换 filepath.Walk，大概可以节省 1/5 的遍历时间

如果用了代码片段或者插件的话关闭排查下。

动态加载块数设置的多大呢？

我这边测试正常，你看下是不是选择了保持已加载内容，大文档的话不要保持，否则页面上元素太多可能会卡顿。

感谢反馈，下个版本改进。

没有办法，Vditor 是完整加载渲染的，不是动态加载的。

估计是被网管加防火墙了，可以咨询一下公司 IT 网管。

你好，购买后不需要手动激活，购买以后账号就自动激活了，感谢支持。

你好，在官网（链滴）上购买的话不需要激活，购买以后账号就自动激活了，感谢支持。

左上角主菜单 - 数据历史 - 数据快照

如果是手动复制文件再同步的话可能会导致本地覆盖云端，因为手动复制以后文件时间就会变成最新时间。

理论上不会，如果遇到问题，可以手动下载云端快照/本地快照回滚。

感谢反馈，请关注 Issue #13210 · siyuan-note/siyuan

仅供参考 Error! Can't initialize plug-ins directory

新建云端目录不要用已经使用过的名称，新建一个比如 main2，在最新数据的设备同步完成后再到其他设备上选择该云端目录，以后就统一使用这个云端目录同步就行。

之前的 main 点一次删除就行了，如果数据多，云端删除会比较慢，暂时不用管它，等过几分钟再看看云端目录列表，应该就不会出现并且释放空间了（如果是使用 S3 的话需要自行到 S3 提供商控制面板删除存储桶）。

PS：你正文提供的日志没有出现同步报错，是不是提供错日志文件了？

请参考这里解决该问题 思源笔记同步指南

编辑操作是个随机事件，所以可以把同步生成的快照看作是随机生成的。

文件历史和数据快照是分开的，互不影响。

手机版思源笔记文档树展开不方便

主要是为了权衡性能和可用性，因为大部分快照都是“随机”产生的，过多的快照对性能会造成较大影响（比如影响启动时间），默认保留 2 个在大部分场景下已经能够应对灾难恢复。

补充一下，快照保留机制是固定保留每天的最后一个，其他随机保留，比如配置为每天保留 10 个，那么每天最后的 1 个快照是肯定会保留的，然后在随机选择 9 个保留，剩余的清理。