盲猜是手机管家之类的扫描到思源的目录，把 apk 当成未使用安装包清理了。

这个 17g 应该只是资源文件附带的多，但是块数和文档字数并不算多，因此在思源承受范围内还算正常。

思源不是自带图片导出吗？

如果你需要的是多页的多图导出，请找插件：多图导出

直接插件集市搜索就行。

思源内核大部分的功能可以分为分为两种，一种是启动时自动执行的内容，这部分看入口。

另一种是通过 web api 调用的功能，这部分看 https://github.com/siyuan-note/siyuan/blob/master/kernel/api/router.go ，需要实现什么就照着函数跳转路径去研究。

一开始不要想着看懂全局，按照自己需要理解并修改的部分去看对应部分就行了。

云端直接覆盖本地，保留历史记录即可。

另外我觉得完全可以在覆盖的时候读取文件。

那外部改动 word 会导致同步到本地出问题吗？我感觉使用最后一个快照似乎没影响。

假如云端快照没更新 word，那 word 不会被覆写。

假如云端快照更新了 word，那使用更新的 word 覆写本地的 word 也不算离谱，毕竟有历史记录在。

更新本地的 word 到云端可以在下一次同步进行。

能否不考虑关闭期间外部导致的文件变动，只使用最新快照进行差分同步？

知道最近修改了哪些文件是为了实现什么效果？

嘶，七月份居然还能被找到……

看样子是社区版吗？那个稳定性自负嘛……

这个可能是因为快照被自动清理了。

参考： 关于 SiYuan v3.1.12 后默认自动清理超过 180 天快照的调查

从头撸一个 pr 不就行了

我给你个参考思路啊：

这个方案最大的问题就是数据量大了之后会卡的离谱，毕竟思源是在一个没有索引、每次操作都要完全读取、反序列化、遍历、修改、序列化、重新全文写入的 json 上工作的……

与其在 json 上苟延残喘，我建议全面转投 sqlite。这东西才算是未来可期，可以承载百万级数据量的属性和表格。

现在的 json 在万行上就开始卡顿了，全部塞一起性能瓶颈只会来得更快。

执行时机是自动同步、手动触发同步、24 小时。所以倒不至于一打开就没了，但是你就要争分夺秒改设置了。

反正自动更新和懒得看更新详情的肯定已经一定程度上丧失选择的机会了。

第一个选项考虑的是没看更新又重视快照的用户。由于默认执行，很可能等到发现快照已经没了。

快照是一个宝贵的资源，当前做得到能从快照中指定抽取单个文件。当前只能整个回滚不代表一直都是。

当然删光了就不用考虑这个了。

不过我现在失去改进这个插件的兴趣了，因为 vv 搓了个大活，enhance 插件里的划词评论……不得不说在这件事上已经达到一个极致了。

下面是视频链接：

https://simplest-frontend.feishu.cn/minutes/obcnjq7455z25m2nnym3m4fs

又一个脚注插件，加油！

我认为的数据安全可能对其他用户来说不重要，那我举个更浅显的例子：思源即将加一个更新，会极大改善用户的体验，涵盖启动速度、移动体验、大文档连续滚动、闪卡究极改进。唯一不妙的是会随机删除 1% 用户的 1% 笔记内容，但他们不一定发现得了。

你觉得应该赞同这个改进吗？

那你觉得比例有多大才能接受呢？80% 的用户体验改善，20% 的用户损失自己认为宝贵的数据可以接受吗？

我觉得做这个比较就不应该。99:1 也不应该，因为作为笔记软件维护用户的数据安全需求就是本分。

我建议这个是出于双方可能损失的判断。

更重视空间占用的忘记打开，那最多就是速度还是一样的慢、空间占用不变。总体来说没改善也没有更糟。

更重视数据安全的忘记关闭，等到发现那就是数据被删光找不回了。

有些人觉得数据安全更重要，有些人觉得减少空间占用更重要，但我觉得承认这两种人都存在是一个重要的前提，在数据快照进行所谓的改进时必须兼顾两方要求，应该是应有之理。

清理快照能提高速度本质上是偷懒之举，本质上因为思源当前没有建立快照索引的快速时间顺序判断机制，所以有多少个快照就要启动时读取多少遍。

删快照减少空间占用这个理由我是认可的，但是删快照来加快启动速度就跟脚上有毛病砍脚一样奇怪。

使用 eventBus 获取 open-menu-image 事件，然后会给一个 detail.menu 塞就是了。

参考 https://github.com/siyuan-note/plugin-sample-vite-svelte/blob/38b19fdb888f5f26004b747739f2403b2087c120/src/index.ts#L436

pdf 导出默认可以使用代码片段和主题的内容，配色插件插入的 css 样式需要处理才能在 pdf 导出中可见。

没做 pdf 导出适配，有人愿意加个 class 再说吧……

开发者已经经过一次尝试，结果是编译的 golang 内核崩溃退出，可能需要等到 google 大发慈悲提供鸿蒙平台支持才行，望周知。

是的，6 个月前更新后忘记推送给 GitHub 了

为任何愿意分享墨水屏体验的点赞

很久没维护，大概插件失效了。