先说结论：如果你也是 Obsidian 重度用户，想在 Windows 电脑、Mac、手机、平板之间免费同步笔记，又不想掏官方 Sync 的订阅费，那这套“阿里云 OSS + Remotely Save 插件”的方案值得花一个下午折腾好。配置完成后基本是无感的，打开任意一端的 Obsidian，等几秒钟就是最新版本。我记得第一次把主力笔记库（将近 500MB、上万个小文件）从电脑完整同步到手机时，整个过程也就是几分钟的事，之后再也没被“这台设备没改到”这种问题烦过。
这篇文章不打算做一堆“为什么要用 Obsidian 记笔记”的铺垫，直接说同步。我会分成六块来讲：先对比当下各条同步路线的实际体验，再走一遍 OSS 云端配置、插件对接、同步机制与常见坑，最后结合我实测的数据聊聊费用与调优，再补充几个把 OSS 当作图床和附件加速器的进阶用法。写这篇东西的目标只有一个：让你照着做就能把同步跑起来，别像我当初一样在 CORS 规则上卡了一晚上。
1. 为什么弃用官方同步？先盘点几条主流路线再动手
很多教程一上来就是“下载插件、填上密钥”，完全没解释为什么这条路值得走。我觉得这部分恰恰是最该想清楚的——同步方案一旦用久了，换路线的迁移成本很高，笔记数量越多越难受。
先说 Obsidian 官方 Sync。它是我认为体验最省心的方案：端到端加密、多端实时同步、版本历史、还有“按需下载”这种能给手机省空间的功能。缺点是贵，按年订阅对很多人来说不是小钱，而且不同区域访问速度时好时坏，真到传大附件的时候不太稳定。除非你的笔记库特别大、或者对隐私加密有硬性要求，否则我并不觉得它是绝大多数人的最优解。
其次是 iCloud。如果你全平台都是苹果设备，iCloud 确实可以考虑。但 Obsidian 官方曾在文档里明确不建议把库直接放在 iCloud 上，因为 iCloud 会把文件拆成数据块管理，库特别大时容易出现“文件在、内容拉不下来”的假死状态。更麻烦的是 Windows 端 iCloud 客户端体验很差，同步冲突或者“幽灵文件”是小概率但真会碰到的事，排查起来极其折磨。微信群和论坛里每隔一阵就会看到有人因为 iCloud 同步炸了来求助，每次原因还都不太一样，这种问题很难给出标准解决方案。
第三条路线是坚果云 WebDAV。它上手简单，配合 Remotely Save 或者自带的第三方插件都行。但这里有个隐藏瓶颈：坚果云免费版每月上传和下载流量各 1GB。如果你只在库里写 Markdown 纯文本还好；可大多数人现在都往笔记里塞截图、PDF，一个月积累下来图片附件可能就有几百 MB。流量用完之后同步会直接失败，观感很不好。
至于 Git 同步，这是程序员圈子里比较流行的方法。对懂 Git 的用户来说确实可靠，而且天然带版本历史，配合 Obsidian Git 插件能做到自动提交推送。但移动端体验不佳——手机上就算能跑 Git 客户端，也不适合频繁处理冲突；而且你的笔记库一旦包含大量二进制附件，仓库体积会极速膨胀。它不是不好，只是对普通用户门槛偏高。
最后就是我这次要讲的路线：Remotely Save 插件 + 兼容 S3 协议的云存储（阿里云 OSS）。Remotely Save 是一个开源插件，作者是 fyears，默认支持 S3 / Cloudflare R2 / 阿里云 OSS / 腾讯云 COS 等对象存储。它的同步方式是文件级的增量同步，跟 Git 那种差异提交不同，跟 WebDAV 那种文件夹映射也不同，理解清楚这一点，后面排错会轻松很多。
选阿里云 OSS 的原因是：国内访问速度快、按量计费便宜、S3 兼容 API 成熟，而且它不止能存笔记附件，以后还能当个人图床、博客存储甚至备份盘用。如果你已经有腾讯云 COS 或者其他 S3 兼容存储，这套配置逻辑是通用的，把 Endpoint 和 Bucket 换掉即可。
2. 阿里云 OSS 端配置：Bucket、RAM 账号和 CORS，一步都不能少
这一节的顺序很关键，我踩过的教训是：先把 OSS 这边的权限和跨域配好，再打开 Obsidian 去填插件，不然两边来回切很容易懵。
2.1 创建 Bucket：地域就近，权限私有，版本控制按需开
登录阿里云控制台，在产品列表里找到对象存储 OSS。首次使用会让你开通服务，流程很简单，按提示操作就行。
进入 Bucket 列表后点击“创建 Bucket”。这里有三个选项值得认真考虑：
- 地域：选离你常用网络最近的地域即可。人在华北就选北京或张家口，在华南就选深圳或广州。不要纠结访问速度那几毫秒的差距，但要记住地域决定 Endpoint，后面插件填的是这个地址。地域一旦创建后不能改，慎重一点没坏处。
- 读写权限：如果你只是自己在多端同步，必须选“私有（Private）”。这里有个大家容易误解的地方：Remotely Save 用自己的凭据去读写 OSS，不需要 Bucket 公开。
- 版本控制：OSS 的版本控制跟 Git 类似，每次覆盖或删除文件时保留旧版本。它对笔记库同步有很大价值——万一某次同步把文件误删了，还能找回历史版本。但要注意开启后存储费用会随历史版本数量增长，纯文本小文件还好，附件多的库需要定期清理旧版本。
创建完成后，把 Bucket 名称记下来，后面每一步都会用到。
2.2 创建 RAM 子账号：别把主账号 AccessKey 填进插件里
我见过不少教程图省事，直接在主账号里创建 AccessKey 填进插件。这种做法的风险很大：主账号 AccessKey 拥有账号下的所有权限，一旦泄露，不仅 OSS 里的数据会被人清空，整个云账号的计费都可能失控。正确做法是创建一个 RAM 子账号，只授予操作这一个 Bucket 的最小权限。
在控制台顶部搜索“RAM 访问控制”，进入用户页面点击“创建用户”。登录名可以叫 obsidian-sync，访问方式勾选 OpenAPI 调用，这样系统会生成 AccessKey ID 和 AccessKey Secret。Secret 只在创建时展示一次，务必先复制保存好。
创建完成后，给这个子账号添加权限策略。我用的策略如下，你可以把obsidian-sync-bucket替换成你自己的 Bucket 名：
{ "Version": "1", "Statement": [ { "Effect": "Allow", "Action": "oss:*", "Resource": [ "acs:oss:*:*:obsidian-sync-bucket", "acs:oss:*:*:obsidian-sync-bucket/*" ] } ] }这段策略的意思是允许这个子账号针对指定 Bucket 做任意操作，但动不了你账号下的其他资源。把权限范围限定到最小，是云资源使用的基本素养。
2.3 配置 CORS 规则：同步失败最常见的隐藏元凶
CORS（跨域资源共享）是浏览器和本地应用请求其他域资源时的一道安全机制。Remotely Save 插件运行在 Obsidian 的 Electron 壳里，它向 OSS 发请求时带了Origin头，如果 OSS 没有在响应头里声明允许这个来源，请求就会被浏览器或 Electron 拦截，表现就是同步一直转圈、报错“Network Error”或者“CORS policy”。
早期官方文档里填写 CORS 时只列了app://obsidian.md这个来源，后来大家发现在移动端（尤其是 Android 和 iOS 的 WebView 环境）来源头可能变成其他值。最省事、也是社区最普遍的做法，是 AllowedOrigin 直接填*。因为 Bucket 本身是私有的，外部人员就算能发起跨域请求，没有有效签名也读不到数据，风险是可控的。
在 OSS Bucket 的“数据安全”->“跨域设置”里，点击创建规则，参照以下配置：
- 来源：
* - 允许 Methods：GET、HEAD、PUT、POST、DELETE 全选
- 允许 Headers：
* - 暴露 Headers：留空即可
- 缓存时间：填 600 秒
保存之后，建议顺手在 OSS 控制台里试传一个文件，确认 Bucket 本身权限和网络都正常，再去 Obsidian 里配置。把云端这一侧先跑通，后面排错的范围会小很多。
3. Remotely Save 插件对接 S3：参数怎么填、首轮全量怎么跑
3.1 安装插件
打开 Obsidian，进入“设置”->“第三方插件”，关闭安全模式后点击“浏览”，在社区插件列表里搜索 Remotely Save。如果网络环境受限导致插件市场加载缓慢或搜不到，也可以到 GitHub 仓库找最新 release 里的main.js、manifest.json、styles.css，手动放入仓库目录下的.obsidian/plugins/remotely-save/文件夹，然后重启 Obsidian 并启用插件。这种方法对任何插件都适用，不局限于 Remotely Save。
3.2 填写 S3 连接参数
启用插件后，在设置页找到 Remotely Save，把远程服务商切到 S3（或者选择兼容 S3 的选项）。此时会看到几个需要填写的字段，逐个解释：
- Endpoint（服务端点）：OSS 的区域接入地址，格式类似
https://oss-cn-beijing.aliyuncs.com。在 OSS Bucket 的“概览”页面可以找到“外网访问 Endpoint”，复制时不要漏掉前面的https://协议头。这里必须用外网地址，不能用 VPC 内网地址，因为你的电脑和手机不在阿里云内网里。 - Region（区域）：填 OSS 控制台里对应的地域 ID，比如华北 2（北京）就填
oss-cn-beijing，华东 1（杭州）填oss-cn-hangzhou。它和 Endpoint 里的地域代码保持一致即可。 - Bucket 名称：你在 2.1 步创建的 Bucket 名，比如
obsidian-sync-bucket。 - Access Key ID / Secret Access Key：2.2 步创建的 RAM 子账号密钥。
还有几个容易忽略的选项：
- 自定义 URL 前缀：保持为空，默认从 Bucket 根路径同步。
- 加密密钥：Remotely Save 支持客户端加密，即把文件加密后再上传。因为你用的是私有 Bucket，OSS 本身已经做了服务端加密，再叠加客户端加密对绝大多数用户来说没有必要。除非你担心阿里云侧能看到文件内容，否则不开启即可，配置项留空。
填完这些之后，我建议先做一次“测试连接”。插件配置页底部有“检查连接”或“测试”按钮，点击后如果看到成功提示，说明 OSS 端和插件端的握手已经通了。这一步如果报错，优先排查 Endpoint 有没有复制错、AccessKey 是否正确、CORS 规则是否生效——三者占了九成的问题来源。
3.3 首次全量同步：给点耐心，别中途打断
首次同步时，Remotely Save 会把仓库根目录的所有文件逐一遍历并上传。影响这个阶段速度的因素主要有两个：文件数量和单文件大小。一个积累了一两年的笔记库，文件数量轻轻松松上万，即使每个文件只有几 KB，逐文件请求耗时也要比想象中长。
实测经验：一个 500MB、文件数量约 1.2 万的库，在百兆带宽下首次全量同步大约需要 15 到 25 分钟。这期间 Obsidian 界面可能会有点卡顿，属正常现象，不要关闭 Obsidian，也不要反复点同步按钮。一次把首轮跑完，后面增量同步都会快得多。
需要注意：Remotely Save 的 S3 后端不走“按需下载”模式，它会把远程库完整下载到当前设备。这意味着手机或平板的本地空间会被整个笔记库占满。如果不想在手机上保留所有历史附件，目前没有一个直接可用的 S3 按需加载方案，你只能用黑名单把某些大附件目录排除在同步范围之外。对这个限制要有心理准备，它决定了你的笔记库不能无限膨胀。
3.4 配置同步频率
在插件设置的“同步频率”区域，我目前的设置是：
- 启动 Obsidian 时自动同步：开启。
- 定时自动同步：开启，间隔设为 5 分钟。
- 关闭 Obsidian 时自动同步：可选，我更推荐手动关闭。因为有些设备（尤其是移动端）后台运行不可控，关停时触发同步反而容易造成冲突。
对多设备同时在线编辑的情况，我会在下面的章节展开讲。
4. 同步机制与冲突真相：它到底怎么传文件、坑都在哪
这一节的内容是我折腾同步过程中最深的感受：很多人配置完同步之后，觉得“文件传上去了就行”，直到某天发现电脑端更新了一个文件、手机端也更新了另一个文件，两边对不上，才开始理解同步背后的机制。
4.1 它的核心同步逻辑是什么
Remotely Save 的基本逻辑是：把 OSS Bucket 当作一个远端文件夹，本地仓库与远端文件夹做逐文件的对比。对比的依据是文件修改时间与大小：本地文件与远端文件的元数据不一致，就判定为需要上传或下载；一致，就跳过。
这个逻辑简单可靠，也是它跟 Git 的重要区别。Git 是基于内容快照的版本管理，管理的是仓库的每一次提交状态；Remotely Save 是文件级增量同步，只关心每个文件当前是否一致。好处是心智模型简单，没有分支、提交、合并这些概念；坏处是它没有真正意义上的“版本历史”，文件一旦被覆盖，旧内容就没有了（除非你用 OSS 的版本控制）。所以我在前面强调开启 OSS 版本控制，本质上就是为了给这个“无版本”的同步方案兜底。
4.2 一个真实冲突的形成过程
假设你上午在公司电脑上修改了每日笔记/2026-03-20.md，下午在手机上用笔记应用又修改了同一个文件的另一段内容，而手机上的 Obsidian 在修改前没有先同步到公司电脑上的版本。此时 Remotely Save 会发现：本地文件时间戳比远端新，远端文件时间戳也比本地记录的新，两边都是“刚刚改过”的状态。
插件的处理方式是：保留其中一个版本作为主文件，把另一个版本复制为带时间戳或冲突标记的副本文件。比如生成2026-03-20 (conflict 2026-03-20-153000).md。这保证了任何一个文件内容都不丢失，但需要你花时间手动合并两个版本。
我的建议是：把自动同步间隔拉到合理范围内，并且养成“切换设备前先手动同步一下”的习惯。手机上修改完笔记，切回电脑前先点一次同步；电脑上改完，离开座位前也同步一次。冲突虽然无法 100% 避免，但这个习惯能让它出现的概率变得极低。
4.3 黑名单与特殊目录的处理
默认情况下，Remotely Save 会把整个仓库目录同步到远端，包括.obsidian（插件的配置、快捷键、主题设置）、.trash（Obsidian 的回收站）、以及一些你手动创建的临时目录。如果你希望不同设备使用不同的插件设置，可以把.obsidian加入黑名单；但大多数人还是希望主题、快捷键同步到所有设备。这个根据自己习惯权衡就行。
.trash目录我建议加入黑名单。Obsidian 删除文件时默认进垃圾桶，如果垃圾桶被同步，删除操作就会在全设备复制一份“回收站”，既浪费流量又占存储。
在插件设置的“黑名单”区域，每行一个关键词，基于通配符匹配。你可以在里面写上：
.trash 临时/ temp/这里的/表示匹配目录。插件会把远程目录和本地目录都做同样的过滤，两边保持对称。
4.4 移动端后台同步的限制与电量权衡
手机端的 Obsidian 是 WebView 套壳，并且受系统限制，后台运行时间很短。iOS 上尤其明显，锁屏之后几乎没有任何 App 能持续同步。Android 上你可以去系统设置里允许 Obsidian 后台运行，但代价是更耗电。
所以对移动端的期待要合理：不要指望手机和电脑实现毫秒级实时同步，能做到“打开 App 时同步”“切换界面时同步”就已经很好了。在移动端设置里把同步间隔调成 10 分钟或更长，反而能减少频繁唤醒带来的电量损耗。
5. 多设备实测：性能调优、费用观察与桌面移动端协作细节
5.1 我实际测出的表现数据
我自己的笔记库从 Notion 迁过来后慢慢积累到 1.6GB，附件占了七成左右。文件总数约 2.4 万个，大部分是图片和 PDF。以下是我用这套方案的实测体验：
- 首次全量上传（电脑端）：耗时约 35 分钟，主要时间花在小文件请求上。
- 增量同步（单次）：正常情况下几秒到十几秒，取决于变化的文件数量。
- 手机首次全量下载：同一 Wi-Fi 环境下耗时约 20 分钟，4G 网络下略慢，但可用。
- 日常使用流畅度：电脑端几乎无感，手机端打开 App 后需要等 3~5 秒拉取最新变化。
这些数据仅供参考，实际表现受文件数量、网络质量、OSS 地域影响很大。但趋势是一致的：文件多、单个文件小才是性能瓶颈，而不是存储服务拉跨。这也是我建议你定期清理附件目录的原因——几万个 5KB 的小文件，同步时逐一比较元数据的成本，远大于文件本身的大小。
5.2 费用账单：一个月下来到底花了多少钱
很多人听说要用阿里云，第一反应是“是不是很贵”。我直接贴出我近三个月的平均账单：
| 费用项 | 计费方式 | 月均实际费用 |
|---|---|---|
| 标准存储费 | 按存储量计费，约 0.12 元/GB/月 | 约 0.2 元 |
| 读写请求费 | 按请求次数计费，极低 | 约 0.05 元 |
| 公网流出流量费 | 按流出流量计费，约 0.5 元/GB | 约 0.5 元 |
| 总合计 | - | 不足 1 元 |
前提是 Bucket 为私有、流量只有你自己跨设备同步时产生。这里的公网流出流量费是计费大头，但每次增量同步也就是几 MB 到几十 MB，真正烧钱的场景是首次全量同步那个月，费用会高一两块，也不会更多。
注意：如果访问 OSS 的流量特别大，建议在控制台开启流量阈值告警，避免账号被盗后产生天价账单。我在 RAM 子账号之外还开启了“费用预警”，虽然云厂商一般都有余额兜底机制，但多一层保护总不是坏事。
5.3 电脑端与移动端协作时的一些细节
多设备协作中，最影响体验的往往不是同步本身，而是 Obsidian 在工作区状态的同步逻辑。你在电脑上打开了某些笔记页签、调整了侧边栏宽度，这些状态也存在.obsidian/workspace.json里。如果两台设备同时在线，这个文件会被反复互相覆盖，导致每次打开 Obsidian，布局都像被重置了一样。
解决方案是：把.obsidian/workspace.json加入黑名单。这样电脑和手机各自保留各自的窗口布局，其他插件设置和主题仍然同步。缺点是新增插件时需要手动在另一台设备上启用一次，但对整体使用体验的改善是值得的。
另外提醒一点：不要在 OSS 控制台里直接删除或修改同步目录下的文件。OSS 控制台上对文件的操作不会通知插件，插件仍然保留着本地记录的远程状态，当你下次同步时，它会把本地文件再次上传覆盖掉你在控制台上的操作。所有对库内文件的整理，都应在 Obsidian 内完成，而不是跑到存储控制台上“手动整理”。
5.4 需要避开的坑位：同一时刻多端同时写
对象存储本质上是没有锁机制的，两个客户端同时对同一个文件执行写操作，后写入的会覆盖先写入的，两台设备之间也没有事务机制。因此，同一时间段内不要在电脑和手机同时编辑同一个笔记文件。
我在实际使用中养成了一套简单的配合方式：工作日白天主要用电脑写，通勤路上用手机看或者补几行临时想法，到家后先等手机同步完再开电脑。如果你有“边用电脑边用手机查资料”的习惯，那就在电脑上写正式内容，在手机上只读不写，或者打开手机上的纯阅读副本——这比任何插件配置更能保证数据安全。
6. 把 OSS 玩得更顺手：图片处理、图床挂载与收尾习惯
同步问题解决之后，我发现 OSS 本身的能力还可以被继续挖掘，而且和 Obsidian 的使用体验直接相关。
6.1 OSS 原生图片处理：笔记里的大图再也不卡了
阿里云 OSS 自带图片处理服务，支持缩放、裁剪、旋转、模糊、水印等操作，处理方式是通过 URL 参数实现。比如你笔记里插入了一张 5000px 宽的截图，原图文件好几 MB，在手机上加载就会比较慢。你可以在 Markdown 里写：
这个链接会在 OSS 侧动态生成一张宽度 800 像素的缩略图，传输体积大幅下降，手机端加载速度能快很多。只要不修改原始的图片文件，原图就一直还在，想保留高清版本随时可以去掉参数。
需要提醒的是：私有 Bucket 的图片 URL 默认无法直接被浏览器访问。如果你要使用这个功能，要么把 Bucket 设为公开读（安全风险上升，不太建议），要么通过自定义域名并开启 CDN 鉴权，或者用 OSS 的临时 URL 签名机制。我的落地做法是只在小范围内使用，不给公开访问，所以这里就不再展开了。
6.2 顺手解决图片管理难题：用附件目录瘦身
Obsidian 默认把粘贴的图片存在根目录，时间一长，根目录会堆满随机命名的 PNG。我建议在设置里把新附件默认存放路径指定为固定目录，比如_attachments/。这跟同步配置本身没有直接关系，但对保持库整洁很重要，也会让后续同步的黑名单优化更直接。
如果你经常在笔记里插入截图，可以搭配自动上传图片类插件，将剪贴板图片直接上传到 OSS 并生成外链，再插入笔记中。这样做的好处是本地不存文件，笔记库体积小，同步飞快。但别忘了私有 Bucket 的访问限制，以及图片外链是否有防盗链需求，一切都以你的实际使用场景为准。
6.3 万一不想用 OSS 了，怎么干净地迁移出去
这套方案有一天你可能会不再想用：要么是笔记量太大，要么是发现了更好的存储后端。此时不要把 OSS Bucket 直接删掉——先确保有一台设备已经完成了同步，手动把它当作“源”，再切换到新方案做首次全量同步，最后确认内容齐全后再在控制台清空并删除 Bucket。
迁移前也可以利用 OSS 的“版本控制”功能，把历史版本导出来做二次备份。不过说实话，只要本地有一份完整的 Obsidian 库，迁移就永远不会丢失数据，云端的角色始终只是“中间跳板”。
6.4 数据安全的最后一道防线：另备一份冷备份
我强调过很多次，但还想再说一次：同步不是备份。如果某一天手滑在电脑上删除了整个笔记目录，Obsidian 会把“已删除”这个状态一并同步到所有设备。就算 OSS 有版本控制，找回全部旧文件依然很折腾。所以我会在电脑上每周末用脚本把整个库压缩打包，放到另一个云盘目录里做冷备份，几个月下来也就几个 GB。成本几乎可以忽略，但带来的安心感非常值。
Obsidian 跨设备同步这件事，本质上是在“成本”“可控性”“省心”三者之间找平衡。官方 Sync 省心但贵，iCloud 免费但有平台锁，Git 免费但门槛高。阿里云 OSS 加 Remotely Save 这条组合路线，算是目前我体验下来综合得分最高的方案：单月成本不足一块钱，所有配置一次完成，之后基本无感，而且不依赖任何特定生态。希望这篇指南能帮你少踩几个我踩过的坑，早日实现“任何设备打开都是最新笔记库”的自由。
