Obsidian 笔记库如何加密同步：用 Cryptomator 配合 Dropbox

笔记库里只有读书摘录时，把它放进 Dropbox，往往是件很自然的事。两台电脑共享一个文件夹，在哪台设备上修改，另一台就能接着看。

但如果里面开始出现合同附件、个人财务记录、尚未公开的项目方案，问题会变得具体：能不能继续用熟悉的 Obsidian 和 Dropbox，又让上传到云端的文件保持加密？

Cryptomator 可以加入这条路径。它在电脑上处理加密和解密，Dropbox 负责传递加密后的文件，Obsidian 则通过解锁后的入口读写笔记。要把这套方案用明白，需要知道文件在哪一步变成密文，以及哪些副本始终留在这条路径之外。

本文以两台桌面电脑之间使用一个敏感笔记库为例。手机上的访问方式另有约束，不能把桌面配置直接照搬过去。

先让笔记经过加密，再交给网盘

Obsidian 的一个仓库，首先是本地文件系统里的一个文件夹。笔记以 Markdown 纯文本保存，附件也是普通文件。换一个文本编辑器，通常仍能读到笔记内容。这种开放性让资料容易迁移，也意味着“放进 Obsidian”本身不会给文件加密。Obsidian 的数据存储方式

假设有一篇 客户报价.md。直接把它放进普通同步文件夹，交给同步工具的就是这份可读文件；在本机先加密，再让同步工具上传，交出去的才是密文。要实现本文的目标，决定性的一步发生在上传之前。

Dropbox 自身已经提供传输加密和服务器存储加密。Cryptomator 增加的是由你掌握解锁凭据的一层保护：云端收到的内容需要先经过你这一层解密，才能成为可读笔记。这里以普通 Dropbox 同步目录为前提；部分团队方案另有端到端加密文件夹，应按其实际配置另行判断。Dropbox 的安全机制、端到端加密团队文件夹

Cryptomator 属于客户端加密工具。“客户端”就是你使用的这台电脑。它加密文件内容及文件、文件夹名称，并混淆目录结构。另一台电脑即使已经下载了这些文件，也需要具备解锁凭据才能读到其中的笔记。Cryptomator 的安全范围

可以把它粗略理解为：每份资料分别装进加密封套，再交给 Dropbox 传送。对应关系是资料与文件、封套与加密处理、运输与同步。不过这个类比只解释分工；软件还要处理目录、文件名和持续修改，并非每次编辑都让用户手动拆包、重新封装。

它适合经常读写的笔记，正是因为加密能够嵌入日常文件操作。你不必每写一段话，就把整个笔记库重新打包一次。

理解两个位置，才不会同步错东西

配置时最容易混淆的，是 Cryptomator 加密库的实际存储位置，与解锁后显示出来的位置。

这里有两个“库”：外层是 Cryptomator 的加密库，内层 Notes 才是 Obsidian 仓库。名字可以自己取，职责不能混在一起。

解锁后，Cryptomator 会提供一个虚拟盘或挂载目录。Obsidian 请求读取笔记时，Cryptomator 按需解密，再把可读内容交给它；Obsidian 写入修改时，数据经过加密，落到外层存储目录。这个机制叫透明加密：应用仍按普通文件的方式工作，加密层处理转换。虚拟盘的工作方式

flowchart LR
    A[Obsidian 读写笔记] <-->|明文读写| B[Cryptomator 虚拟盘]
    B <-->|按需加解密| C[Dropbox 本地密文目录]
    C <-->|同步密文| D[Dropbox 云端]
    D <-->|同步密文| E[另一台电脑的密文目录]

另一台电脑也要用 Cryptomator 解锁，再让那台电脑上的 Obsidian 读取虚拟盘。

虚拟盘并不意味着 Cryptomator 必须在硬盘上长期保存第二份完整明文库；它通过即时加解密提供访问。但应用取得明文后，仍可能自行生成缓存、快照或导出文件。这两件事要分开理解。Cryptomator 的架构说明

因此，Dropbox 应同步外层密文目录，Obsidian 应打开内层解锁视图。 如果把可读笔记另复制一份放进普通 Dropbox 文件夹，那份副本就绕过了加密层。锁定原来的加密库，也不会替你收回它。

把这条路径在两台电脑上走通

初次配置，可以先用几篇无敏感信息的笔记、一张图片和一个 PDF 建立测试库。测试的目的，是看完整流程能否成立，包括附件、链接和换机后的再次编辑。

1. 在第一台电脑建立外层加密库。 安装并配置好桌面端软件，在 Cryptomator 中新建加密库，把存储位置选在 Dropbox 的本地同步目录。为它设置独立的强密码，并将恢复密钥保存在库外的安全位置。Cryptomator 本身不承担云端同步，仍需 Dropbox 客户端工作。创建加密库
2. 解锁后建立内层笔记库。 在虚拟盘里新建 Notes，让 Obsidian 将它作为仓库打开。复制现有库试用时，应同时检查附件、相对链接和隐藏的 .obsidian 配置目录；先确认复制来的插件与同步设置，避免顺带启用另一条上传路径。
3. 让密文在本地保持完整。 在 Dropbox 中把整个加密库目录设为“可离线使用”，并等待下载完成。“看得见文件名”不等于文件内容已经在本地；仅在线文件可能只是占位符。对这套需要反复读写的方案，保留完整本地密文更容易排除网络和按需下载带来的干扰。Dropbox 的离线文件说明
4. 在第二台电脑添加已有加密库。 先让 Dropbox 同步完整目录，再在 Cryptomator 中添加这个已有库并解锁。随后，用 Obsidian 打开虚拟盘里的 Notes。不要在第二台电脑另建一个同名空库，以为名称一样就会自动连接。

接着做一轮往返验证：在第一台新增笔记并引用附件，等同步完成后，在第二台检查文字、图片和链接；再从第二台修改一个段落，让第一台收到变化。还可以在密文完整下载后断网，确认本地能正常解锁和读取；离线期间的修改，要联网同步后才会到达另一端。

这些是依据产品机制设计的验证步骤，不是对任意系统、插件和软件版本的兼容保证。正式迁移时，保留原库与独立备份，直到自己的设备完成这轮验证。

保存、锁库与同步完成，是三个不同的时刻

假设你在电脑 A 改完一份合同笔记，立即合上电脑，走到电脑 B 前继续写。B 打开的仍可能是旧版，即使 A 上的修改已经保存。

原因很简单：本地保存只代表修改进入了本机的文件处理流程；Dropbox 上传和另一端下载，还需要各自完成。Cryptomator 锁定加密库，则是关闭解锁后的访问入口。锁库不会替 Dropbox 完成上传，也不是“现在才开始加密”。 文件在正常写入时已经经过加密。文件访问与锁定、Dropbox 的同步与离线行为

比较稳妥的换机习惯是：在 A 上结束编辑并关闭该 Obsidian 库，确认能够正常锁库，再等 Dropbox 完成上传；到 B 上先等下载完成，再解锁并打开笔记。这样做减少了切换时尚未写完或尚未传完的变量。使用过程中可以持续同步密文，不必每次修改都先锁一次库。

如果两台电脑离线时都改了同一篇笔记，问题就更明显。A 修改了报价，B 修改了交付日期，两个版本都可能包含需要保留的内容。加密层没有足够的信息替你判断应该保留哪句，更不负责把业务含义合并正确。

发生冲突时，Cryptomator 能将某些云端冲突副本以带后缀的可读文件名显示出来，但仍需用户检查版本并合并内容。保留两个版本再判断，比仅凭修改时间删除其中一个更可靠。也不要直接在外层密文目录中挑选看不懂的文件进行“整理”。Cryptomator 的冲突处理

所以，给文件加密之后，错峰编辑、等待同步、处理冲突这些习惯仍然有用。它们解决的是不同版本如何汇合的问题。

保护能到哪里，要看明文在哪里出现

这套路径可以让云端存储的笔记内容和名称保持加密，但文件数量、存储大小及时间戳等信息仍可能暴露。它也不会把已经失守的电脑重新变安全：笔记解锁后，拥有相应访问权限的程序能够读取明文。安全范围与不加密的元数据

对 Obsidian 用户，尤其值得检查的是“文件恢复”。这是核心插件，会保存笔记的完整快照；官方文档明确说明，快照位于库外的全局设置位置。因此，即使 Notes 放在 Cryptomator 虚拟盘里，这些快照也不会自动受到该加密库的保护。Obsidian 文件恢复

这并不表示 Dropbox 必然拿到了快照，而是提醒我们：云端只同步密文，与本机没有可恢复的明文副本，是两个要求。如果后一个要求也很重要，就需要检查快照设置、导出位置和备份目标，并结合设备本身的保护措施安排恢复能力。

插件同样位于这条边界上。Obsidian 官方说明，社区插件会继承应用的访问权限，能够访问文件和连接网络。如果一个插件读取笔记并把内容发送到外部服务，磁盘上的加密层无法阻止这次发送。敏感库只启用确有需要、来源可信的插件，才与前面的保护目标一致。Obsidian 插件安全说明

迁移还有一个时间上的边界：把今天的文件放进加密库，不会反过来加密昨天已上传的副本。旧的明文库、导出文件和云端历史版本需要单独盘点；Dropbox 的历史恢复能力受方案及保留范围约束，不能把“当前位置已删除”理解为“所有旧副本都不存在”。Dropbox 版本历史

手机端的问题则更多是应用能否取得合适的访问入口。Cryptomator 在 iOS 上可以通过“文件”应用访问解密内容，但“能打开一个文档”并不等于“能让 Obsidian 持续读写整个库”。Obsidian 要处理链接、改名和附件，需要整个仓库的访问能力；官方也未将 Dropbox 列为 iOS 上正式支持的同步方式。Cryptomator 的 iOS 文件访问、Obsidian 跨设备同步说明

Android 也应按具体版本核查跨应用目录访问，不能因为三个应用都能安装，就推断这条链路已经贯通。如果手机是主要写作设备，应先验证手机端完整读写和回传，再决定是否采用这套方案。把文件解密导出到手机的普通文件夹，虽然可能便于编辑，却又产生了需要单独保护和同步的副本。

能打开备份，这套方案才算走完

加密之后，恢复需要同时满足两个条件：数据还在，而且你拥有解密所需的凭据。

在普通密码保护的库中，Cryptomator 先生成库使用的关键密钥，再用从密码计算出的另一把密钥保护它们。解锁时先恢复这些关键密钥，才能读取文件。恢复密钥提供另一条恢复访问的路径，因此必须像密码一样保密，并且不能只存在同一个加密库里。密钥架构、密码与恢复密钥

密码与恢复密钥都不能代替文件备份。一个容易理解的反例是：如果误删同步到了另一台电脑，两端都失去某个文件，恢复密钥不会把已经消失的文件重新生成。反过来，即使完整密文还在，所有可用的解锁凭据都丢了，也不能指望厂商代为重设密码。密钥和数据缺一不可。

还要避免一个误解：更改库密码通常不会把全部文件重新加密。它改变的是对既有密钥的保护；如果旧的密钥文件版本仍可被取得，弱旧密码带来的风险未必随着改密消失。因此，初建库时就应使用足够强且独立的密码。改密机制与历史版本限制

我更倾向于给这类敏感库保留独立、有历史版本的备份。若备份外层密文目录，就在结束写入、正常锁库并确认本机数据完整后保存整个库，包含密文数据及相关配置文件。不要只挑几个看起来像附件的大文件复制走。Cryptomator 的备份建议

恢复演练可以很具体：将一份完整备份恢复到另一个、不参与云同步的位置，在 Cryptomator 中作为第二个库添加并解锁，检查几篇笔记和附件能否读取。官方也推荐通过这种方式恢复文件；它能避免直接用旧文件覆盖正在工作的同步库。从备份恢复文件

对主要在桌面电脑之间使用、需要经常修改的敏感笔记，这套组合有明确价值：Obsidian 保留文件式工作方式，Dropbox 继续传递文件，加密在两者之间完成。代价是多管理一层解锁入口，并认真对待冲突、凭据和恢复。

是否值得采用，可以落到一件具体的事上：换一台电脑，你能否从同步下来的密文读到正确笔记；再换成一份独立备份，能否找回误删的附件。两条路径都走得通，这些笔记才既能日常使用，也有机会在出问题时回到你手里。