先说结论如果你也是 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 的“数据安全”-“跨域设置”里点击创建规则参照以下配置来源*允许 MethodsGET、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 Key2.2 步创建的 RAM 子账号密钥。还有几个容易忽略的选项自定义 URL 前缀保持为空默认从 Bucket 根路径同步。加密密钥Remotely Save 支持客户端加密即把文件加密后再上传。因为你用的是私有 BucketOSS 本身已经做了服务端加密再叠加客户端加密对绝大多数用户来说没有必要。除非你担心阿里云侧能看到文件内容否则不开启即可配置项留空。填完这些之后我建议先做一次“测试连接”。插件配置页底部有“检查连接”或“测试”按钮点击后如果看到成功提示说明 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插件的配置、快捷键、主题设置、.trashObsidian 的回收站、以及一些你手动创建的临时目录。如果你希望不同设备使用不同的插件设置可以把.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 这条组合路线算是目前我体验下来综合得分最高的方案单月成本不足一块钱所有配置一次完成之后基本无感而且不依赖任何特定生态。希望这篇指南能帮你少踩几个我踩过的坑早日实现“任何设备打开都是最新笔记库”的自由。 
长河君 · 2026/9/16 22:08:11 · 阅读 1.2k Obsidian多端同步实战：阿里云OSS+Remotely Save免费方案详解
先说结论如果你也是 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 的“数据安全”-“跨域设置”里点击创建规则参照以下配置来源*允许 MethodsGET、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 Key2.2 步创建的 RAM 子账号密钥。还有几个容易忽略的选项自定义 URL 前缀保持为空默认从 Bucket 根路径同步。加密密钥Remotely Save 支持客户端加密即把文件加密后再上传。因为你用的是私有 BucketOSS 本身已经做了服务端加密再叠加客户端加密对绝大多数用户来说没有必要。除非你担心阿里云侧能看到文件内容否则不开启即可配置项留空。填完这些之后我建议先做一次“测试连接”。插件配置页底部有“检查连接”或“测试”按钮点击后如果看到成功提示说明 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插件的配置、快捷键、主题设置、.trashObsidian 的回收站、以及一些你手动创建的临时目录。如果你希望不同设备使用不同的插件设置可以把.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 这条组合路线算是目前我体验下来综合得分最高的方案单月成本不足一块钱所有配置一次完成之后基本无感而且不依赖任何特定生态。希望这篇指南能帮你少踩几个我踩过的坑早日实现“任何设备打开都是最新笔记库”的自由。