很多用 Obsidian 做笔记库的人，在选同步方案时会有一种感觉：各家方案用起来”差不多”——不都是把文件从一台设备复制到另一台设备吗？
但如果用上三个月，差异就会浮现出来。改了一个字，有的方案要传几十 KB 甚至整个文件；弱网环境下，有的方案反复失败，有的方案悄无声息地就完成了。两个人同时编辑同一篇笔记，有的方案直接生成一堆文件名带乱码的冲突副本，有的方案能清晰地标记冲突区域让你做合并决策。
这些差异不在表面，在底层的技术原理。
这篇文章不罗列功能清单，而是把几个核心技术原理拆开来看：块级增量传输、策略化同步、Diff3 三方合并、云端历史版本与回收站，以及 Nutstore Sync 在这些原理层面的具体实现。如果你是个渴望理解”为什么它更好”的读者，这篇文章就是为你写的。
原理一：全量同步 vs 块级增量同步
传统方案的工作方式：改一个字，传整个文件
大多数同步方案（包括依赖系统文件同步的 iCloud、OneDrive 个人版，以及若干开源同步工具）采用的基础同步策略是全量同步。它的工作流程大致如下：
- 检测变化：文件系统监控发现某个文件被修改
- 计算哈希：对文件整体计算 MD5 或 SHA-1
- 上传/下载：将整个文件传输到远程，或从远程拉取整个文件
这个流程在文件体积较小时问题不大。但对于 Obsidian 用户来说，情况完全不同——一个知识库可能包含上万个 Markdown 文件，其中单篇笔记从几百字到几千字不等，还有图片附件。更关键的是，这些文件是频繁修改的：你今天可能只在 50 篇笔记里各改了一两句话。
在全量同步方案下，你改了一句，它就要把 50 篇笔记文件从头到尾重新上传一遍。一篇 5000 字的笔记，你改了一个标点符号，它上传的是 5000 字的完整文件。弱网环境下，大文件传输失败率显著上升，而且每次失败后要重新校验整个文件。
Nutstore Sync 的块级差分传输
Nutstore Sync 底层基于坚果云的智能增量同步引擎。这套引擎的核心工作方式是块级差分传输：
- 文件被逻辑切分为固定大小的数据块（chunk）
- 修改时，只对变化的数据块重新计算哈希
- 仅传输发生变化的数据块，在远端重新组装
这意味着什么？一篇 Obsidian 笔记有 5000 字，你只改了其中的一个标题文字。Nutstore Sync 检测到变化后，识别出只有一个数据块发生了变动，只传输这几十个字节。全量方案要传输 5000 字，Nutstore Sync 传几十个字节——差距是两个数量级。
在实测中，这个原理带来的体验差异非常明显。两小时的会议期间，你在笔记本上做了 20 次修改，每次修改相隔几分钟。Nutstore Sync 在每次保存后只传输变化的数据块，累积传输量可能只有几十 KB。而全量方案每次保存都传输整篇笔记，累积下来就是几 MB。在手机移动网络环境下，这个差异甚至意味着”能否稳定同步”和”总能同步成功”的区别。
对于一个迭代数年的知识库来说，块级增量传输不止是快，更是让同步行为变得”轻量可预测”——你不会看到上传进度条卡在那里一动不动，因为它每次只传一点点。
原理二：基础同步 vs 策略化同步
大多数方案只有”双向同步”一种模式
操作系统级别的文件同步方案（如 iCloud Drive、OneDrive 个人版）通常只提供一种同步模式：双向同步。所有接入设备地位平等，每台设备都可以无差别地读写云端文件。
这种模式在个人使用场景下问题不大，但在多设备场景中就开始捉襟见肘了。比如：
- 手机只想查看笔记不要写入，因为手机编辑容易误触
- 公共电脑（图书馆、公司会议室）只想下载到本地后清除，不留缓存
- 另一台电脑只想接收某个文件夹的最新版本，不参与修改
这些需求在”只有双向同步”的方案里没法满足。你可以做的是：同步完所有文件后，手动把手机端的 Obsidian 设为只读模式——但这不是一个可靠的方案，因为一旦忘记设置，手机端的任何误操作都会写回知识库。
Nutstore Sync 的 5 种同步策略：设备角色分配框架
Nutstore Sync 实现了 5 种同步策略，本质上是让每台设备在同步网络中扮演不同的角色。这不是功能列表，而是一个设备角色分配框架：
- 双向同步：所有修改双向流动，适合主力设备
- 仅发送：修改只从本地上传，不从云端拉取变更——适合采集设备（比如在手机上快速记录想法），保证写入但不受他人修改干扰
- 仅接收：只从云端拉取变更，本地的任何修改不被上传——适合阅读设备，手机或平板浏览笔记库时不用担心误写
- 仅接收并还原本地变更：在仅接收的基础上，如果有本地修改，自动还原到云端版本——适合公共设备，每次打开时重置到最新内容
- 仅发送并覆盖云端变更：将本地版本强制推送到云端并覆盖远端——适合恢复场景或单向备份
在实践中，”仅接收”和”双向同步”的组合最常见：主力电脑用双向同步，手机和平板用仅接收。这样你在手机上浏览笔记库时，可以做任何标注、删除、重命名——所有操作都只停留在本地，不会影响到云端和主力设备上的版本。
而实现这一切配置的基础是 OAuth 单点登录。每台设备通过 OAuth 协议向坚果云授权即可接入同步网络，不需要手动输入密码或配置 WebDAV 地址。换设备时，在新设备上打开 Nutstore Sync，点击授权，几秒钟就完成了接入。
插件是通过坚果云账号登录的，安装插件前记得先注册一个坚果云账号，坚果云官网注册完成后在每一台设备上分别授权即可使用。
原理三：简单覆盖 vs 三方合并冲突解决
传统方案遇到冲突时的两种糟糕选择
当两台设备几乎同时编辑同一篇笔记时，就会发生同步冲突。这个场景在实际使用中并不少见——你早上在办公室电脑上打开了一篇笔记开始写，离开前忘记关闭；晚上在家用笔记本打开同一篇笔记添加新内容，然后两台设备都试图同步。冲突发生了。
传统方案处理冲突的方式通常有两种：
- 生成冲突副本：生成一个类似 “笔记_v2.md” 或 “笔记 (XX的冲突副本).md” 的新文件，原始文件保留其中一个版本。结果是你不得不手工比对两个文件的内容差异来手动合并。如果这种情况频繁发生，你的笔记库会慢慢被命名混乱的副本文件污染。
- 静默覆盖：后来的同步操作直接覆盖之前的版本，毫无痕迹。这是最危险的——你今天在办公室写的内容，被昨晚在家编辑的旧版本覆盖了，而你完全不知道。
Nutstore Sync 的 Diff3 合并算法
Nutstore Sync 采用 Diff3 三方合并算法来解决冲突。这个算法的名字来自 diff（文件比对）的 “3-way” 版本——它比对的不是两个版本，而是三个：
- 本地版本（当前设备的修改）
- 云端版本（另一台设备的修改）
- 共同祖先（两个版本分叉前的基础版本）
算法将三方文本逐一比对，自动合并不冲突的部分，只在真正发生冲突的区域插入 Git 风格的冲突标记。这些标记格式如下：codeCopy
<<<<<<< 本地版本
你在本地写入的内容
=======
另一台设备写入的内容
>>>>>>> 云端版本
冲突标记之间的区域是确实存在歧义的修改——算法无法判断该保留哪一边，所以交给人类做最终决策。
在实际使用中，这种做法的好处非常明显。一本 500 页的 Obsidian 知识库，两台设备在 50 页里各自做了修改，只有 3 页被双方同时编辑了同一段。Diff3 合并会：自动合并那 47 页的修改，只在 3 页的冲突位置插入冲突标记。你只需要检查带有标记的 3 页内容即可，其余 47 页完全不需要干预。
值得一提的是，Nutstore Sync 的 AI 辅助功能可以进一步优化这个体验。选中冲突标记区域，AI 会分析两边的修改意图，给出一个结构化的合并建议。你可以选择接受 AI 的合并方案，或手动编辑最终版本。这不是自动覆盖——它是一种”辅助决策”，让你在难以判断时多一个参考意见。
Nutstore Sync 提供的冲突策略一共 4 种：无冲突合并（不创建冲突标记，自动合并可合并部分）、Diff3 合并（生成 Git 风格冲突标记）、本地优先（保留本地） 和 服务器优先（覆盖本地）。默认推荐的 Diff3 合并是平衡安全性和自动化的最佳选择。
原理四：无回收站 vs 云端历史版本与回收站
Obsidian 本地删除操作的不可逆性
Obsidian 本身运行在本地文件系统上。你在 Obsidian 中删除一篇笔记，本质上就是操作系统层面的文件删除。如果你没有配置版本控制系统（如 Git）或开启系统回收站，被删除的文件就永远消失了。
这也包括误删除的情况：你不小心选中了一个文件夹按了 Delete，整个文件夹里的 200 篇笔记瞬间消失。如果没有外部保护机制，这就是灾难性的。
坚果云的历史版本与回收站机制
坚果云为每个存储在云端的文件保留了历史版本记录。每次文件修改后自动保存历史版本——不是基于时间周期，而是基于文件实际变更。每修改一次，就产生一个可回溯的版本点。
历史版本的核心价值：
- 按时间线回溯：可以查看某个文件在过去 N 天内或 N 个版本内的任何一次快照
- 版本间对比：两两对比版本间的内容差异，不是”看到版本 1 和版本 2″，而是”看到版本 1 到版本 2 之间哪些文字变了”
- 恢复任意版本：选择任一历史版本，一键恢复到当前状态
配合回收站（被删除的文件自动进入回收站，保留一定期限），理论上你可以在任何误删除或错误修改发生后进行恢复。从技术原理上讲，数据恢复能力不是一个功能，而是一条退路——你可以在本地放心编辑，因为你知道云端有一层保护。
这个机制的核心原理并不复杂：坚果云在每次同步上传时，不是覆盖原有文件，而是将新版本作为新的数据对象存储，保留旧版本的引用。这类似于 Git 的提交模型——每次变更是新增，不是覆盖。而回收站则是在文件被删除时，将文件移入一个隔离的存储区域，而不是物理删除。
原理对比汇总
| 技术维度 | 传统同步方案（块级/全量方案） | Nutstore Sync（智能增量方案） |
|---|---|---|
| 传输方式 | 全量传输，改一个字传整个文件 | 块级差分传输，仅传变化数据块 |
| 同步策略 | 仅双向同步一种模式 | 5 种策略（双向/仅发送/仅接收/还原本地/覆盖云端） |
| 冲突算法 | 生成冲突副本或静默覆盖 | Diff3 三方合并（生成 Git 风格冲突标记）+ AI 辅助 |
| 数据恢复 | 依赖系统回收站或无保护 | 历史版本（每修改存一个版本）+ 独立回收站 |
FAQ
Q1：增量同步和全量同步在传输量上到底能差多少？
根据我们日常使用的实测观察：一个 5000 字的 Markdown 笔记文件，全量同步每次保存都上传约 10 KB（含文件元数据和哈希校验）。Nutstore Sync 的块级同步在修改个别短语时上传量通常在 100 字节以内。如果每天笔记库有 50 次文件修改动作，月传输量差异大约是 15 MB（全量） vs 300 KB（增量）——两个数量级。
Q2：Diff3 合并和普通的自动合并有什么区别？
普通的自动合并（Git 的 recursive 模式等）尝试自动解决一切冲突，但遇到无法自动解决的情况，会直接报告”合并失败”并中止操作。Diff3 三方合并会坚持到最后一刻——它会将所有可自动合并的部分先行合并，只在真正无法判断的地方插入冲突标记。Diff3 的主要优势在于引入了”共同祖先”作为参考基准，这让合并决策有了一个客观的参照系。
Q3：OAuth 比直接使用 WebDAV 密码认证更安全吗？
是的。WebDAV 密码认证要求在每台设备上存储用户的坚果云账号密码，这意味着密码在多个存储位置暴露。OAuth 单点登录使用短期令牌（access token）和刷新令牌（refresh token），就算令牌泄露，也有有效期限限制，且可以随时在坚果云管理后台撤销。OAuth 不在第三方设备上暴露主账号密码。
Q4：.obsidian 目录可以同步吗？怎么做到配置跟随？
可以。Nutstore Sync 允许手动选择是否同步 .obsidian 目录（默认不同步）。如果你希望主题、快捷键、核心插件设置在不同电脑之间保持一致，可以开启 .obsidian 目录的同步。需要注意的是：如果你在不同设备上使用不同的插件集合，建议在每台设备上分别安装所需插件，仅同步核心配置而不同步插件二进制文件。
Q5：远程目录（Remote Vault）的工作原理是什么？
远程目录功能不要求文件完全下载到本地，而是通过虚拟文件系统挂载云端目录。PC 端和移动端都支持。你打开这个远程目录时，文件列表和元数据是实时加载的，点击文件时才按需下载内容。对于只读查阅场景（比如在手机上快速翻一篇旧笔记），不需要占用本地存储，也无需等待完整同步完成。
Q6：Nutstore Sync 是否会有请求频率限制？遇到限制怎么办？
坚果云对 API 调用有请求频率限制，这属于任何公开 API 的常规保护措施。限制的具体阈值取决于账号类型（付费账号通常有更高的配额）。如果不小心触发了限制，最有效的办法是先歇半小时再重试。在半小时间歇期内，API 调用配额会逐渐恢复。建议的预防方法是：不要在一次大量文件修改后立即全部同步，可以分批保存修改。
Q7：如果我停止订阅，本地文件还能正常访问吗？
能。Nutstore Sync 的工作原理是在本地维护一个同步目录，所有笔记文件都保存在本地磁盘上。停止订阅后，双向同步功能停止，但本地已有的文件完全可以正常访问和编辑。你只是失去了跨设备同步和历史版本回溯的能力。
总结
同步方案的选择不是在选”能不能同步”——几乎任何方案都能做到基础同步。真正的差异在于：同步系统在边界情况下的行为。改少量文字时传多少数据、冲突发生后你怎么处理、误删除后能不能恢复、不同设备能不能扮演不同角色——这些技术原理层面的差异，决定了方案能否长期稳定使用。
Nutstore Sync 的技术架构围绕三个核心设计：块级增量传输控制传输成本、策略化同步管理设备角色、Diff3 三方合并和版本回滚管理数据安全。对 Obsidian 知识库来说，这三个设计比单纯的”文件复制”重要得多。
如果你正在搭建自己的 Obsidian 知识库，可以先用坚果云跑起来，在真实使用中感受这些技术原理在日常场景中的表现：