有一个场景，只要你用 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（下载）还是 fetch+merge（双向），你先看 status（执行列表），你审查 diff（确认哪些文件被修改），然后才 commit 和 push（执行同步）。
对于把 Obsidian 当作核心生产力工具的用户来说，这种"可控性"不是锦上添花，而是必不可少的。你的笔记 vault 可能包含正在写作的书稿、项目文档、客户会议记录——这些内容的价值远远超过一个文件传输工具几百毫秒的传输延迟优化。你对同步过程的可知性和可控性的需求，远大于对传输速度几毫秒差异的关注。
方向选择与冲突策略的联动考量
一个容易被忽略的细节是：方向选择和冲突策略是联动的。同一个冲突文件，选择"仅上传"和选择"双向"时，插件的处理逻辑完全不同。
仅上传模式下的"冲突"：你选择仅上传，但云端有一个比你本地更新的版本。这时候插件的逻辑是——你明确说了只上传不下载，所以即使云端版本更新，它也不会拉下来覆盖你的本地。云端版本保持不变，你的版本被推上去成为新版本。这意味着：如果你的本地版本实际上比云端版本旧（比如你忘了先在另一台设备上同步过），仅上传会导致云端更新版本被覆盖。
仅下载模式下的"冲突"：你选择仅下载，但本地有一个你没推过的修改版本。同样，插件尊重你的选择——只下载不推送。你的本地修改暂时保留在本地，不会被覆盖到云端，但也不会被上传。下次同步时这些本地修改会重新出现在执行列表中。
双向模式下的"冲突"：这才是冲突策略（无冲突合并/最新版本/跳过等）真正生效的模式。两台设备的修改在云端相遇，按照你选择的策略处理。
这个联动逻辑说明了一个重要的使用原则：在你确认"本地是最新版本"之前，不要轻易选择"仅上传"。如果你不确定本地是不是最新，双向模式 + 无冲突合并是更安全的选择。仅上传和仅下载是为那些"你明确知道自己在做什么"的场景设计的。
Q&A
Q1: 执行列表在移动端也能用吗？
能。移动端的执行列表界面做了适配，文件列表可滚动，操作类型用图标标注，确认按钮放在拇指容易触及的位置。移动端还支持分块下载——对于超过设定阈值的大文件，自动拆分成小块传输，避免一次传输失败就要重传整个文件。
Q2: 如果我在执行列表里取消了很多文件不同步，下次会怎么样？
下次手动同步时，之前被取消的文件会再次出现在执行列表中。插件不会因为你取消过一次就"记住"并永久忽略这些文件——它每次都会重新扫描并展示完整的变更清单。
Q3: 我能不能设置某些文件或文件夹永远不同步？
可以通过 Nutstore Sync 的排除规则实现。在设置中可以配置排除模式（类似 .gitignore 的 glob 模式），匹配到的文件和文件夹不会出现在变更扫描和执行列表里。
Q4: 同步方向能不能设为默认？
可以。你可以在设置中指定默认同步方向。比如你大多数场景使用双向同步，就设双向为默认。偶尔需要仅上传或仅下载时，在触发同步前临时切换。
Q5: 自动同步模式下，方向选择和执行列表还有效吗？
自动同步（定时触发）使用你在设置中指定的默认方向和冲突策略，不弹出执行列表确认。执行列表是手动同步的专属功能。这个设计的逻辑是：自动同步讲求无感，手动同步讲求可控。
Q6: 如果我在执行列表确认之后、同步执行过程中网络断了怎么办？
Nutstore Sync 底层使用坚果云的智能增量传输——已传输的部分不会丢失，网络恢复后从断点继续。对于移动端的分块下载，中断后只需要重传当前失败的那个分块，而不是整个文件。
Q7: 执行列表会显示文件大小吗？
会。每个待上传或待下载的文件旁边标注了文件大小。这在移动网络下特别有用——你可以根据文件大小决定是否要在当前网络条件下同步。
Q8: 和 Obsidian 官方 Sync 相比，方向选择和执行列表是优势还是差异化？
Obsidian 官方 Sync 采用的是端到端加密的点对点同步模型，同步粒度非常细，体验也很流畅。它不提供方向选择和执行列表，因为它的设计哲学是"完全自动化的无缝同步"。Nutstore Sync 的方向选择和执行列表是对另一种使用哲学的回应——有些用户希望对自己的数据流动有更明确的感知和控制。两种哲学没有对错，取决于你的使用习惯。
