有一个场景只要你用 Obsidian 跨设备同步几乎一定遇到过。你在公司电脑上改了一整天项目文档回到家打开笔记本准备继续。同步插件检测到云端有变更开始自动拉取——这很好。但它同时也把你笔记本上三天前的旧版本推了上去覆盖了你今天在公司改的内容。你不知道它什么时候开始同步的、传了哪些文件、为什么覆盖了你的新版本。你只看到文件内容变了然后手忙脚乱去翻历史版本。这就是黑盒同步的典型后果。大多数 Obsidian 第三方同步插件包括通过 WebDAV 手动配置的 Remotely Save采用的是被动双向同步模型——插件自动检测变更、自动推送、自动拉取。整个过程对用户来说是一个黑盒子你不知道哪些文件即将被上传、哪些文件即将被下载、哪些文件存在冲突。你只知道它在同步。Nutstore Sync 在 2026 年的更新中用两个功能彻底改变了这个局面同步前执行列表和手动选择同步方向。这篇文章我会用真实使用场景逐一实测这两个功能并分析它们对日常笔记工作流带来的实际影响。旧版同步模型的三个痛点在深入新版功能之前先梳理一下旧版被动双向同步的三个核心痛点——这些痛点不是 Nutstore Sync 独有的而是几乎所有第三方 Obsidian 同步插件的通病。痛点一你不知道即将发生什么。你修改了 10 个文件删除了 2 个文件在另一台设备上也改了 3 个文件。当你点击同步按钮或者插件自动触发同步这些操作会混合在一起执行。你没有机会在同步前看一眼变更摘要——就像 Git 用户在git push --force之前没有git status一样危险。痛点二你不能按场景选择同步方向。有些场景你只想下载有些你只想上传有些你想双向合并。但旧版同步模型只有一个方向——双向。你在高铁上用手机热点改了几行笔记插件就开始尝试把整台设备的所有变更都推上去消耗你宝贵的流量。你没有办法说现在只下载上传等到了有稳定 Wi-Fi 的地方再说。痛点三同步失败原因不可见。同步失败了你看到的是一个通用错误提示。是网络问题是某个文件被锁定了是云端空间满了你只能猜测然后重试期望这次能成功。这三个痛点合在一起构成了同步焦虑——你不敢放心地点同步因为你不知道会发生什么。而新版 Nutstore Sync 解决的就是这个问题。执行列表把同步变成可审计的事务新版 Nutstore Sync 在每次手动同步之前会先展示一个执行列表面板。这个面板列出了本次同步将要执行的所有操作分为三类上传本地修改过的文件即将推送到云端下载云端有更新但本地尚未拉取的文件删除本地或云端标记为删除的文件同步后会从另一端也删除每个文件旁边标明了操作类型和文件路径。你可以逐项确认也可以取消勾选你暂时不想同步的文件。实测场景一选择性同步——只传核心笔记不传草稿我模拟了一个场景vault 里有 15 个文件发生了变更其中包括 10 篇正在写作的文章需要同步到云端以便在另一台设备上继续以及 5 个随手记录的草稿片段暂时不想同步。打开执行列表15 个待上传文件清晰列出来。我逐一取消 5 个草稿文件的勾选然后确认执行。结果只有 10 篇文章被上传草稿留在本地。下次同步时插件会再次提醒我这 5 个草稿还未同步——你没有忘记它们只是主动推迟了同步。这个场景在日常使用中非常常见。不是所有修改都需要立即同步到所有设备——有时候你只是随手写了几行还不成形的想法不想让它们污染其他设备上的 vault 视图。实测场景二删除确认——避免误删扩散另一个高风险场景是删除。如果你在设备 A 上删除了一个文件然后触发了双向同步设备 B 上的同一个文件也会被删除。如果这是误删你需要在设备 B 上手动恢复。有了执行列表之后删除操作会在预览中被明确标注为删除类型。你有机会在确认之前意识到等一下这个文件我不应该删然后取消这个删除操作的同步。与 Remotely Save 的差异实测场景三移动网络下的流量管控我在手机热点环境下做了一个测试vault 里有一个 45MB 的 PDF 附件发生了变更标注了新的高亮和批注同时有 8 个普通笔记文件也有修改。打开执行列表PDF 文件被标记为待上传旁边标注了 45MB 的文件大小。在移动热点下上传一个 45MB 的文件不仅消耗大量流量而且网络波动可能导致上传失败。我取消了 PDF 文件的勾选只同步了 8 个普通笔记文件。PDF 的同步被我推迟到晚上回到 Wi-Fi 环境之后。这个场景的价值在于执行列表不只是让你知道要传什么更是让你按网络条件做决策。在移动网络下你随时可以根据文件大小和当前网络质量做出先传小的大的等 Wi-Fi的实时判断。与 Remotely Save 的差异不只是有没有这个功能Remotely Save 不提供执行列表预览。你触发同步之后无论是手动还是自动插件直接在后台执行上传和下载操作。如果你想了解同步了哪些文件需要事后去查看日志——而日志通常只是时间戳和文件路径的罗列没有操作类型分类也没有确认/取消的交互机会。这个差异的本质不是多一个功能少一个功能而是两类同步哲学的区别。Remotely Save 的哲学是同步应该像心跳一样自动、无感——它在设计上刻意减少用户参与追求的是 set-and-forget 的体验。这种哲学对于日常轻度使用的用户确实友好。Nutstore Sync 的执行列表哲学是同步应该像提交代码一样可审计——它把每一次同步当作一个有意识的决策点让用户在同步前有机会审查、选择、确认。这种哲学对于把 Obsidian 当作核心生产力工具、vault 内容价值高的用户更有吸引力。两种哲学适合不同用户画像没有绝对的对错。但如果你属于后者——vault 里有重要的写作项目、客户资料、研究数据——你大概率会更偏向可审计的一方。手动选择同步方向三个场景三种策略新版 Nutstore Sync 允许你在每次手动同步时选择方向上传仅上传、下载仅下载、双向合并同步。这个功能解决的核心问题是——不同场景下同步的含义是不同的。场景一单设备高强度编辑后上传你在公司电脑上花了一整天写文档改了 20 多个文件新增了 5 个附件。你确认公司电脑上的本地版本是最新、最完整的。但家里的笔记本可能还开着处于休眠状态上面的版本是三天前的。策略选择上传仅上传。这个操作只做一件事——把本地所有变更推到云端。不会从云端拉取任何内容因此不存在被旧版本覆盖的风险。等你回到家打开笔记本再选择下载仅下载把云端的最新内容拉下来。场景二新设备或重装后首次拉取你换了一台新电脑或者重新安装了 Obsidian。vault 文件夹是空的但云端有你过去一年的所有笔记。策略选择下载仅下载。这个操作会把云端所有内容拉取到本地。因为选择了仅下载即使本地有一些残留的空文件夹或配置文件也不会被推送上去覆盖云端内容。场景三日常双向维护两台设备都在活跃使用各自有一些修改。你需要把两边的变更合到一起。策略选择双向合并同步。这是默认模式插件会同时上传本地变更和下载云端变更并按照你选择的冲突策略处理可能出现的冲突文件。为什么这个设计很重要手动选择方向的本质是把判断权还给了用户。你说我现在处于什么场景、我确认本地是最新版本、我只需要上传——这个判断是插件无法替你做的因为插件不知道你在物理世界的上下文。相比之下Remotely Save 的同步模型是检测变更→自动双向同步。你可以在设置中调整同步间隔比如每 5 分钟但无法在一次具体操作中选择方向。这在大多数日常场景下足够用但遇到上述单设备高强度编辑或新设备首次拉取的场景时就只能祈祷双向同步不出问题。执行列表 方向选择的组合价值把这两个功能放在一起看它们构建了一套完整的同步工作流你根据自己的场景选择同步方向上传/下载/双向插件根据你选择的方向生成待执行操作列表你逐项审核这个列表确认无误后执行同步完成你知道每一步发生了什么这个流程和 Git 的工作流相似——你决定是 push上传还是 pull下载还是 fetchmerge双向你先看 status执行列表你审查 diff确认哪些文件被修改然后才 commit 和 push执行同步。对于把 Obsidian 当作核心生产力工具的用户来说这种可控性不是锦上添花而是必不可少的。你的笔记 vault 可能包含正在写作的书稿、项目文档、客户会议记录——这些内容的价值远远超过一个文件传输工具几百毫秒的传输延迟优化。你对同步过程的可知性和可控性的需求远大于对传输速度几毫秒差异的关注。方向选择与冲突策略的联动考量一个容易被忽略的细节是方向选择和冲突策略是联动的。同一个冲突文件选择仅上传和选择双向时插件的处理逻辑完全不同。仅上传模式下的冲突你选择仅上传但云端有一个比你本地更新的版本。这时候插件的逻辑是——你明确说了只上传不下载所以即使云端版本更新它也不会拉下来覆盖你的本地。云端版本保持不变你的版本被推上去成为新版本。这意味着如果你的本地版本实际上比云端版本旧比如你忘了先在另一台设备上同步过仅上传会导致云端更新版本被覆盖。仅下载模式下的冲突你选择仅下载但本地有一个你没推过的修改版本。同样插件尊重你的选择——只下载不推送。你的本地修改暂时保留在本地不会被覆盖到云端但也不会被上传。下次同步时这些本地修改会重新出现在执行列表中。双向模式下的冲突这才是冲突策略无冲突合并/最新版本/跳过等真正生效的模式。两台设备的修改在云端相遇按照你选择的策略处理。这个联动逻辑说明了一个重要的使用原则在你确认本地是最新版本之前不要轻易选择仅上传。如果你不确定本地是不是最新双向模式 无冲突合并是更安全的选择。仅上传和仅下载是为那些你明确知道自己在做什么的场景设计的。QAQ1: 执行列表在移动端也能用吗能。移动端的执行列表界面做了适配文件列表可滚动操作类型用图标标注确认按钮放在拇指容易触及的位置。移动端还支持分块下载——对于超过设定阈值的大文件自动拆分成小块传输避免一次传输失败就要重传整个文件。Q2: 如果我在执行列表里取消了很多文件不同步下次会怎么样下次手动同步时之前被取消的文件会再次出现在执行列表中。插件不会因为你取消过一次就记住并永久忽略这些文件——它每次都会重新扫描并展示完整的变更清单。Q3: 我能不能设置某些文件或文件夹永远不同步可以通过 Nutstore Sync 的排除规则实现。在设置中可以配置排除模式类似 .gitignore 的 glob 模式匹配到的文件和文件夹不会出现在变更扫描和执行列表里。Q4: 同步方向能不能设为默认可以。你可以在设置中指定默认同步方向。比如你大多数场景使用双向同步就设双向为默认。偶尔需要仅上传或仅下载时在触发同步前临时切换。Q5: 自动同步模式下方向选择和执行列表还有效吗自动同步定时触发使用你在设置中指定的默认方向和冲突策略不弹出执行列表确认。执行列表是手动同步的专属功能。这个设计的逻辑是自动同步讲求无感手动同步讲求可控。Q6: 如果我在执行列表确认之后、同步执行过程中网络断了怎么办Nutstore Sync 底层使用坚果云的智能增量传输——已传输的部分不会丢失网络恢复后从断点继续。对于移动端的分块下载中断后只需要重传当前失败的那个分块而不是整个文件。Q7: 执行列表会显示文件大小吗会。每个待上传或待下载的文件旁边标注了文件大小。这在移动网络下特别有用——你可以根据文件大小决定是否要在当前网络条件下同步。Q8: 和 Obsidian 官方 Sync 相比方向选择和执行列表是优势还是差异化Obsidian 官方 Sync 采用的是端到端加密的点对点同步模型同步粒度非常细体验也很流畅。它不提供方向选择和执行列表因为它的设计哲学是完全自动化的无缝同步。Nutstore Sync 的方向选择和执行列表是对另一种使用哲学的回应——有些用户希望对自己的数据流动有更明确的感知和控制。两种哲学没有对错取决于你的使用习惯。