Obsidian 最让人又爱又恨的一点，就是它真的“本地优先”。没有云数据库，没有中心服务器，你的笔记就是一个文件夹里的一堆 Markdown 文本文件。这种设计带来极高的自由度和隐私安全感，但也留下一个绕不开的坎——同步。白天在公司 Windows 电脑上写了一半的笔记，地铁上想在手机里接着看，晚上回家想在 Mac 上继续改，只要没把同步理顺，Obsidian 的跨端体验基本直接归零。
这几年我试过市面上几乎所有能跑通的路子，从官方 Sync 到网盘、Git、自建服务都折腾过，踩过的坑比大多数教程里写的都多。这篇就专门聊 Obsidian 同步。我会把当前主流的同步路径全部拉出来，从原理、成本、移动端体验、冲突概率几个维度做横向实测，然后按人群给出选择建议。无论你是刚入坑的新手，还是被同步折磨了很久的老玩家，应该都能从中找到适合自己的组合。站在 2026 年这个时间点看，Obsidian 的同步生态已经比前几年成熟太多，但“没有完美方案”这件事依然成立，关键看你怎么组合。
1. 同步之前，先搞清楚 Obsidian 同步的本质
很多人一上来就装插件、配 WebDAV，结果同步出问题后完全不知道从哪排查。原因很简单，大家没先理解 Obsidian 的同步到底在同步什么。
1.1 为什么 Obsidian 不能像在线笔记那样“天然多端同步”
Obsidian 的核心定位是本地 Markdown 笔记软件，它读写的是你磁盘上的普通文件，没有官方云数据库。你新建一个库（Vault），本质上就是指定一个文件夹，里面存着.md笔记、图片、PDF 附件，以及一个记录配置和插件的.obsidian目录。
这意味着，如果你想在两台设备上看到一样的笔记内容，唯一办法就是让两个文件夹里的文件保持一致。所以 Obsidian 的所有同步方案，底层做的事情都是一样的：把同一个目录的数据，在多个终端之间双向搬运。
这里有个关键认知：同步不是备份。备份是把数据复制一份存起来，主库删了备份还在；同步则是尽量让多端看起来一模一样，你在一台设备上删了某个文件，另一端也会跟着删。很多新手把这两个概念混在一起，最后数据没了我都是备份找回来的。
另外，Obsidian 多端同步时真正难处理的，不只是笔记正文，还有.obsidian目录里的东西——主题、快捷键、插件配置、核心插件开关状态都在这。你可能会发现笔记都同步过去了，但手机上的 Dataview 查询语法全部失效，十有八九是插件配置没同步对。这个后面我会专门说。
1.2 同步前必须做的一步：把库结构和附件体积先理清
不管选哪个方案，我都建议先把自己的库整理一遍再开始。Obsidian 同步效率低，很多时候不是方案的问题，而是库里塞了太多不该塞的东西。
第一，检查附件。如果你的库里塞了几个 GB 的 PDF、高清图片，那任何同步方案都会变慢，流量也会被大量消耗。我见过有人把整个“个人资料库”都堆进 Vault，连几十 GB 的影音文件也往里放，同步自然卡到怀疑人生。正确做法是：笔记库只放需要考虑内容关联的文件，大体积资料走单独的云盘或 NAS 路径。
第二，把.obsidian目录了解清楚。里面有几个文件很关键：workspace.json记录的是窗口布局、打开的标签页，这个文件极易在同步时冲突；plugins文件夹和appearance.json等则是插件和主题配置，同步后能不能“无缝切换”就看它们。后面配置同步方案时，我会专门讲怎么处理workspace.json。
第三，明确你的真实使用场景。是“笔记本+手机阅读”这种低频同步，还是“公司电脑+家里电脑+手机+平板”全天候多端编辑？这两种场景对方案的实时性、冲突处理要求完全不同，选型结果也会不一样。
2. 主流同步方案原理盘点
目前社区里能被广泛验证的同步方案，大致分为五类：官方 Obsidian Sync、网盘实时同步、Git 版本管理、Remotely Save 云端同步插件，以及 Syncthing / LiveSync 这类 P2P 或自建方案。每一类的原理、优劣势、成本差异都很大，我先逐个拆开讲清楚，再说怎么选。
2.1 官方 Obsidian Sync：端到端加密的省心方案
Obsidian 官方同步服务是我见过最“无感知”的方案。它的原理是：你的 Obsidian 客户端把文件加密后上传到官方服务器，其他设备通过同一个账号解密拉取。整个过程是端到端加密的，服务端拿不到明文内容，所以在隐私性上很能打。
官方 Sync 有几个独有优势。第一，它直接内置在客户端里，不需要装任何插件，也不需要理解 WebDAV、S3 这些概念。第二，支持选择性同步，你可以只同步某些文件夹，比如把附件目录排除掉。第三，提供版本历史，误删误改后可以直接从同步历史里恢复，这个比很多第三方方案都省心。第四，它是实时推送的，编辑后几秒内其他设备就能收到，不需要“手动拉取”或等待定时任务。
代价也很直接：收费。个人版大概每月 4 美元左右，年付有一定折扣。这个价格对国内用户来说不算便宜，尤其当你只是想在手机上看一眼笔记，会觉得自己花这钱有点冤。但如果你把“稳定、无冲突、不用折腾”折算成时间成本，它其实是综合体验最高的方案。
适合人群很明确：愿意付费换取省心的用户，尤其是对技术不敏感、不想折腾 Git 和云服务的 Obsidian 重度用户。
2.2 网盘实时同步：OneDrive / 坚果云 / Dropbox
网盘同步的思路最简单粗暴：把 Vault 文件夹放在云盘同步目录里，让云盘客户端帮你把文件搬运到其他设备。这个方案的优势是零额外成本——只要你本来就有网盘，基本不用装新东西。
但实际体验要打不少折扣，尤其是移动端。电脑端还好说，Windows 和 macOS 上 OneDrive、Dropbox 的客户端都很成熟，Vault 放在同步文件夹里基本能自动工作。问题出在手机和平板上：iOS 上 Obsidian 无法直接读取 OneDrive 的本地占位文件，你得先通过 Files App 把笔记文件夹“下载”到本地，然后 Obsidian 再以文件夹方式打开，整个过程很别扭。安卓端情况稍好，但也要看云盘 App 后台同步是否及时。
另一个麻烦是冲突。云盘同步的冲突处理非常初级，经常出现“文件名 (1)”这种复制副本，一旦你同一时间在电脑和手机上都编辑同一篇笔记，大概率会生成两个文件而不是被智能合并。多端编辑频繁的人用网盘方案会非常痛苦。
坚果云是个特殊情况。它支持 WebDAV 协议，理论上适合和第三方工具配合。但坚果云免费版的流量限制非常紧，30 天内上传和下载各只有 1GB/3GB 左右额度，如果你的库有不少图片，很快就会被限额卡住。所以坚果云更适合搭配 Remotely Save 插件做低频同步，而不是当作实时同步的挂载盘。
2.3 Git 版本管理：适合需要版本历史的进阶用户
Obsidian Git 插件是目前开发者群体里很流行的方案。原理是把 Vault 当作一个 Git 仓库，插件定期执行git add、commit、push，另一台设备上执行pull拉取更新。
这个方案的灵魂是“版本管理”，不只是同步。你每次提交的记录就是一个时间快照，改错了随时可以回滚，这对长篇写作、知识库维护来说价值巨大。而且 Git 仓库可以托管到 GitHub、GitLab、Gitea 等平台，免费、容量大，没有云盘流量限制。
但它的缺点同样明显：第一，不是实时同步，默认间隔可能是 10 分钟或更久，手动 push 又容易忘，跨设备连续性不如官方 Sync。第二，冲突处理需要一定能力，两台设备同时修改同一个文件时，Git 会标出冲突标记，你需要手动打开文件解决，这对非开发者来说是灾难。第三，移动端体验很差，iPhone 上需要借助 Working Copy 这类第三方 Git 客户端配合快捷指令，Android 上要装 Termux 写脚本，折腾成本非常高。
所以 Git 方案更适合已经有 Git 使用经验、并且需要版本回滚能力的人。把它当作“主力同步 + 备份”的组合一部分，比单独作为唯一同步方案更合理。
2.4 Remotely Save：轻量、跨平台、可接多种后端
Remotely Save 是社区里目前口碑最好的同步插件之一。它本质是一个“定时双向同步器”：你配置一个远程存储位置（比如 S3 兼容对象存储、WebDAV、Dropbox、OneDrive），插件每隔指定时间把本地修改上传上去，同时把远端的新变动拉下来。
它相比网盘同步的优势在于：不受本地云盘客户端限制，iOS、Android、Windows、macOS 全平台都能统一体验；相比官方 Sync 的优势在于：你可以选择自己的存储后端，成本掌控在自己手里，数据也可以自己管理。
我用它配合 S3 兼容存储用了很长时间，整体稳定度能到 90 分。配置时几个参数很关键：同步方式建议选“双向同步”，方向搞反会导致数据互相覆盖；同步间隔一般选 5 到 15 分钟，太短容易产生并发请求冲突，太长则跨设备体验迟缓；一定要设置排除列表，把.obsidian/workspace.json和一些临时文件排除掉。
它的缺点是：需要依赖第三方存储服务，如果你是技术小白，第一次配置 S3 Bucket、Access Key 这些概念会有一定学习成本。另外，它不是真正实时，两条设备同时高频修改时仍可能出现冲突副本。
2.5 P2P 与自建同步：Syncthing / LiveSync
Syncthing 属于 P2P 同步工具，设备之间直接传输数据，不走中心服务器，隐私性很强，而且完全免费。它比较适合所有设备都在同一个局域网内的场景，比如家里有 NAS、台式机、笔记本和手机，内网传输速度飞快。但如果你的设备分散在外网环境，Syncthing 依赖中继服务器打洞，速度可能一般。
iOS 端 Syncthing 没有官方 App，只能借助 Möbius Sync 这类第三方客户端，体验不算理想。安卓端有官方 App，后台同步相对靠谱。
Self-hosted LiveSync 则是更进阶的方案，它用 CouchDB 做后端，实现真正的双向实时同步，编辑完几乎毫秒级同步到所有设备。效果确实惊艳，但部署门槛也高：你需要一个可公网访问的 CouchDB 实例，还要配置好 HTTPS 证书、账号密码和指纹认证。我身边能真正把它跑稳的人不多，大多数都在第一次配置时就被各种证书报错劝退了。适合有时间折腾、有一定服务器运维基础的人。
3. 横向测评：我用半个月实测了五大方案
光讲原理不够，我把自己常用的一个库作为测试对象，在不同设备上分别用五类方案跑了半个月，记录真实体感。下面把测评过程和结果公开，不搞虚的。
3.1 测评环境与测试场景
测试库基本情况：一个约 2.5GB 的 Obsidian 库，包含 1200 多篇 Markdown 笔记、约 400 张图片和少量 PDF 附件，安装了 Dataview、Excalidraw、Templater 等常用插件。
测试设备：
- 主力机：Windows 11 台式机
- 办公机：macOS 笔记本
- 移动端：iPhone 15 Pro、一台 Android 平板
- 家居设备：一台 NAS，用于 Syncthing 和 LiveSync 测试
测试场景模拟真实日常：工作日早上在公司电脑写工作笔记，通勤路上用手机翻阅和快速记录，晚上在家用 Mac 整理知识库，周末在平板上做 Excalidraw 图表。重点关注三件事：跨设备能多快地看到修改；是否出现冲突文件；移动端编辑体验是否顺畅。
3.2 六项评分与横向对比
我先说结论，然后给完整的评分表。这次实测下来，最稳的还是官方 Obsidian Sync，几乎没有冲突，实时性也最好。Remotely Save 紧随其后，在合理配置下能达到接近官方 Sync 的体验，但偶尔会有小延迟。网盘方案在电脑端还行，一到手机端就掉链子。Git 方案适合作为备份，但作为纯同步主力还是太折腾。
| 维度 | 官方 Sync | 网盘同步 | Git 插件 | Remotely Save | Syncthing |
|---|---|---|---|---|---|
| 实时性 | 5 | 3 | 2 | 4 | 4 |
| 稳定性 | 5 | 3 | 3 | 4 | 4 |
| 移动端体验 | 5 | 2 | 1 | 4 | 3 |
| 冲突处理 | 4 | 2 | 2 | 3 | 3 |
| 成本 | 2 | 4 | 5 | 4 | 5 |
| 数据安全/隐私 | 4 | 3 | 5 | 4 | 5 |
| 综合推荐度 | 4.5 | 2.5 | 3 | 4 | 3.5 |
这个评分表带有明显的主观感受，但大致能反映问题。官方 Sync 在各项都比较均衡，唯一的短板是付费；Remotely Save 是“最像官方方案”的自助方案，我后续给出了具体配置建议；网盘同步看着不用花钱，其实暗坑最多，冲突文件多的那天让我差点原地爆炸。
3.3 关于冲突率的实测记录
我特别要讲讲冲突率，这是普通教程不会细说的地方。Obsidian 自带的冲突处理机制是：当它检测到本地文件与远端文件在同一时间点都有修改时，会保留一个版本，并把另一个版本另存为“xxx (conflicted copy)”。这个机制能保命，但会产生大量垃圾文件，你要是不定期清理，库里会有越来越多奇奇怪怪的副本。
我实测半个月的冲突记录是：
- 官方 Sync：只有 1 次冲突，而且是我故意在手机和电脑同时开同一篇笔记测试出来的。日常使用几乎零冲突。
- 网盘同步：7 次冲突，主要集中在移动端编辑场景。OneDrive 同步有延迟，手机和电脑改同一篇时特别容易出“文件名 (1)”副本。
- Git 插件：由于我是低频手动 push/pull，实际冲突只有 2 次，但每次解决都需要打开编辑器处理
<<<<<<<标记，体验很硬核。 - Remotely Save：3 次冲突，基本发生在同步间隔较短（比如 3 分钟）且多端同时编辑时。调长到 10 分钟后，冲突明显减少。
- Syncthing：2 次冲突，和局域网环境下的速度相关，但移动端 App 的后台限制也会加剧问题。
想减少冲突，最有效的办法不是选什么神仙方案，而是改使用习惯：同一时刻，只在一个终端编辑当前需要修改的笔记。多人协作同一篇笔记时，冲突无法彻底避免，只能靠版本管理或官方 Sync 的版本快照救场。
4. 按场景给你推荐配置
选同步方案不是“哪个分数高就选哪个”，而是“结合你的场景选择最不痛的那个”。下面按常见使用人群给出组合建议，可以直接照着抄。
4.1 预算充足的全端重度用户：官方 Sync 为主，Git 备份为辅
如果你是 Obsidian 每天都要用、手机电脑平板一个都不能少的人，我建议直接上官方 Obsidian Sync。理由很简单：它把所有设备拉平到一个统一的体验维度，不需要你理解底层原理，也不需要维护额外服务。版本历史功能还能在误删时救你一命。
我还建议再加一个“周末 Git 备份”的辅助策略，比如每周末让 Obsidian Git 插件自动把整个库推到私有仓库。这不是为了实时同步，而是给库留一条独立于官方服务器的退路——万一账号出了问题，至少还有一份版本化备份可以恢复。
这个组合的成本主要是官方订阅费，但换算成你省下的折腾时间，我觉得非常值。很多人为了省几十块钱，花上几个周末配置各种免费方案，最后数据丢了或者冲突满天飞，不划算。
4.2 预算敏感用户：Remotely Save + 对象存储（或 WebDAV）
不想花钱，我首选 Remotely Save 插件。它能把 Obsidian 变成“自带云端同步”的应用，而且配置不难。
第一种配法，用 S3 兼容对象存储，比如阿里云 OSS、腾讯云 COS、Cloudflare R2、Backblaze B2。我个人推荐 Backblaze B2 或 Cloudflare R2，因为免费额度够用，个人笔记库基本花不了几个钱。配置步骤大致是：先在存储服务商处创建 Bucket，开启 S3 API 接口，拿到 Access Key 和 Secret Key，然后在 Remotely Save 插件里填入 Endpoint、Bucket、Key 等信息，设置同步方式为“双向同步”，间隔设成 5 到 10 分钟。
第二种配法，用坚果云 WebDAV 先跑起来。坚果云支持的 WebDAV 协议可以直接被 Remotely Save 识别，配置更直观：打开坚果云设置里的 WebDAV，填一个应用专用密码，然后回插件里填服务器地址和账号就行。优点是一分钟配完，缺点是流量非常有限，建议只放文本型笔记，图片和附件尽量本地管理。坚果云流量在这个场景下就是“低频同步”才够用。
4.3 开发者或笔记量很大的人：Git 为主，注意冲突策略
如果你本来就是开发者，熟悉 Git，那 Obsidian Git 会带来其他方案给不了的版本控制优势。但我不建议直接用 Git 做唯一同步主力，更合理的组合是：Git 管理版本历史 + Remotely Save 做多端同步，两者并存，各司其职。
这样组合，你既能享受 Remotely Save 的多端实时体验，也可以在每次 Git push 后获得一个稳定的历史快照。即便同步插件出了问题，Git 仓库里还保留着最近一次完整状态。
开发者用户还要注意一个问题：仓库体积增长很快。如果库里有大量附件，Git 历史会越来越臃肿，可以考虑把附件目录排除出 Git，或者定期用 git filter 清理历史。另外，不要在.gitignore里随便忽略.obsidian，否则插件配置同步不完整。
4.4 团队协作共用库：官方共享库或 Git 协作
如果你要和团队成员共用一个 Obsidian 库，情况比个人同步复杂很多。两个典型方向：
方向一是官方 Sync 的共享库功能，它允许多人同时连接同一个远端库，由官方处理冲突和并发。这个方案体验最好，代价是每个成员都要付费订阅，成本较高。
方向二是走 Git 协作流程，团队成员各自克隆仓库，通过 commit、push、pull 合并变更。这个方式免费且协作流程清晰，但有门槛：不是每个人都会处理冲突。如果团队里有人操作失误，很容易把别人的修改覆盖掉。
我强烈不建议的是：让一群人通过第三方云盘共享同一个 Vault 文件夹。云盘同步不是为多人并发设计的，互相覆盖、文件丢失只是时间问题。
5. 踩坑实录：常见问题与排查方法
这些年在各种群里看到无数人问 Obsidian 同步问题，很多坑我自己也踩过。整理五个高频问题，每个都附上排查思路和解决方法。
5.1 同步后插件设置丢失，Dataview 查询全部失效
这个问题几乎每个用第三方同步方案的人都会遇到。症状是：手机或新电脑上打开库，笔记都在，但主题变了、插件没了、Dataview 代码变成纯文本。
原因基本就一个：.obsidian目录没有被正常同步，或者被排除列表挡掉了。很多人在配置 Remotely Save 时，照抄网上的“排除列表”，把.obsidian整个排除了，结果核心配置完全没同步过去。正确做法是：.obsidian目录必须同步，但其中workspace.json建议排除——这个文件记录的是当前打开的标签页和布局，属于个人临时状态，同步它只会频繁产生冲突。
另外，如果你切换了设备，记得在“设置-关于-切换配置目录”里重新选择配置目录，或者确认设备上的“配置文件夹”名称一致。
5.2 iCloud 里放 Vault 的隐患
我见过太多 iPhone 用户习惯性把 Obsidian 库放在 iCloud 目录里，然后不定期遇到“文件消失”“笔记内容是空的”这类问题。iCloud 的设计理念是省空间，它会自动把文件转为占位符状态，等你需要时才下载。但对 Obsidian 来说，这很致命——本地文件夹里的文件不在物理磁盘上时，Obsidian 可能读取失败，甚至误认为文件不存在而产生异常副本。
还有文件系统层面的差异：iCloud 对某些文件名的处理比较特殊，比如文件名大小写变化、重音符号等，这些在某些跨平台同步场景中会导致同步错乱。我的建议很直接：不要把 Vault 直接放在 iCloud 目录里。iPhone 用户优先用官方 Sync，或 Remotely Save 手动拉取，避免让 iCloud 参与 Obsidian 库的实时同步。
5.3 坚果云 WebDAV 流量不足，同步越来越慢
用坚果云配合 WebDAV 时流量一定不够：免费版 30 天内上传只有 1GB、下载 3GB 左右。Obsidian 第一次全量同步可能直接干掉一大半额度，之后每次小同步都在慢慢消耗，一旦限额，客户端登录和同步都会失败。
解决办法有三条。第一，缩小同步范围，把附件较多的文件夹从同步列表里排除，或移到其他位置。第二，降低同步频率，从“实时”改成“手动触发”或“每天固定时间拉取”，减少小文件的长期流量消耗。第三，优先选择 S3 对象存储方案，它们按量计费，对个人笔记库来说成本通常可以忽略不计。
5.4 Git 冲突的实战处理
用 Obsidian Git 插件时，最常见的报错是 push 被拒绝，或者拉取后本地文件出现<<<<<<< HEAD标记。
出现 push 被拒绝，说明远端有本地产地上游的新提交，这时需要先把远端变更 pull 下来，解决可能的冲突后再 push。我个人更推荐一个小技巧：在插件设置里打开“Pull changes on startup”和“Push on commit”，让它每次提交后自动 pull 一次，降低冲突概率。
如果已经出现了冲突标记，不要慌。直接用 VS Code 打开这个 md 文件，它会提供可视化冲突解决界面，选择接受哪边修改，或者两边都保留，合并保存后再正常提交。
5.5 手机后台同步失效，打开 App 才更新
移动端后台同步是老大难。iOS 上 Obsidian 的后台运行权限本来就受限，即便你用官方 Sync，也做不到像微信一样实时接收。解决思路是接受现实：iOS 端同步靠“打开 App 时触发”，你只要打开 Obsidian，它就会执行拉取更新。不需要额外设置，反而更省电。
Android 端稍微复杂，由于各家 ROM 的后台管理策略不同，观察 App 可能被系统杀掉。建议在系统设置里把 Obsidian 加入“不受电池优化限制”的白名单，并在应用设置里打开自启动权限。如果用了 Remotely Save，还可以在插件设置里开启“启动应用时自动同步”，保证每次打开 App 都能拉到最新内容。
6. 我的最终结论：没有银弹，但可以组合出最优解
折腾了这么多年，我最大的心得就是：Obsidian 同步领域不存在“一个方案打天下”的银弹，每个方案都有它的天然边界。但通过合理组合，完全可以让你的多端体验无限接近 Notion 那种“打开就是最新内容”的状态。
6.1 不同人群的最优组合
| 人群特征 | 首选组合 | 备选方案 |
|---|---|---|
| 多端重度用户、不在乎订阅费 | 官方 Obsidian Sync + 周末 Git 备份 | Remotely Save + S3 |
| 预算有限、要免费 | Remotely Save + 坚果云 WebDAV / Cloudflare R2 | Syncthing（全设备可内网） |
| 开发者、要版本历史 | Git 插件 + Remotely Save | 官方 Sync |
| 局域网内多设备 | Syncthing 或 LiveSync | 官方 Sync |
| 团队共享库 | 官方 Sync 共享库 | Git 协作流程 |
6.2 我目前的个人配置
我现在的主力配置是：Remotely Save + Cloudflare R2，同步间隔 10 分钟，排除掉workspace.json和临时目录；同时在 NAS 上跑一个定时任务，每小时把整个库增量备份到 Git 仓库。
选择这个组合，主要是平衡了成本、控制力和稳定性。我不想为同步付月费，又不想把数据全押在第三方网盘的同步机制上。R2 的费用我用了几个月基本在零点几美元量级，几乎可以忽略不计。日常手机上打开 Obsidian，最多等几秒就能看到新内容，多端编辑时的冲突也基本被排除列表和合理的同步间隔压住了。
6.3 切换同步方案前的三条建议
最后，聊几点过来人的经验。
先说最要紧的一条：任何切换操作之前，先做一个完整的本地备份。不只是复制一份库文件，我建议先用 Git commit 打一个 tag，或者打个 zip 包放到安全位置。同步方案切换过程中最容易出现“两端互相覆盖”的窗口期，如果没有备份，一个失误就是几十个小时的心血。
再说第二点：新方案先在次要设备上跑一周，不要一上来就把所有主力设备都切换过去。比如你先在 Android 平板上搭配 Remotely Save 试一周，确认稳定了再切换到手机和办公电脑。这样可以避免把不确定因素扩散到日常生产环境。
结尾分享一个小技巧：给每个设备设置不同的“设备名”，这在 Obsidian 的同步插件和 Git 提交记录里都有对应设置。一旦出现冲突文件，你能立刻看出冲突来源是哪台设备，排查效率会高很多。别问我是怎么知道的，问就是当年花了一整天才定位到某个冲突副本其实来自公司电脑。
