手机打开 Obsidian 后不停地重新加载，连一篇笔记都读不完。电脑上花了很多时间整理的库，到了手机上却用不起来——这是我这次遇到的问题。
我仍然在用 iCloud 同步。看到想风的 Obsidian 入门文章提醒云盘可能产生冲突副本，再想到库里检查出的疑似副本，我又开始担心笔记会不会被改乱。
这次我和 Codex 一起排查、调整配置和自动写入程序，手机已经恢复正常。图片能显示，连续启动三次稳定；我在手机里把测试笔记的一处文字改成“正常”，Mac Mini 和 MacBook Pro 也都收到了。
这里有两件事需要分别处理：手机反复加载，先恢复启动和阅读；文件出现副本，再核对版本与写入来源。下面先写普通用户能用上的恢复步骤。自动程序和 Git 的处理放在文末选读，不使用它们，也可以完成前面的排查与验收。
先把笔记留住
出现异常时，先停下正在修改同一批笔记的自动任务，其他设备也暂时别接着改那篇有问题的文件。把能够正常读取的库复制到 iCloud 之外的备份位置，抽查几篇重要笔记和附件。电脑上能看到文件名，还要确认正文和附件确实可以打开。
手机上如果有尚未传到电脑的新内容，先单独保存。只有确认数据在别处完整可读，才考虑重装应用。
我确实做过“删除 App 后重装”。但这是我的恢复经历，不能直接省略前面的数据检查，让所有人都先卸载。同步会传播文件变化，恢复时需要另外保留一份能够找回旧内容的备份。
手机反复加载：先用最少的功能打开
我当时重新安装 Obsidian，并选择在安全模式下打开，之后恢复了正常。
这次重装和安全模式一起发生，我没有单独查出是哪一个插件导致的，也没有证据证明 iCloud 是手机反复加载的唯一原因。
如果你还能进入设置，可以先在“第三方插件／社区插件”里打开“受限模式”，暂时让社区插件停止运行，再重启观察。官方说明中，受限模式会忽略已安装的社区插件，插件文件仍然保留。受限模式说明
能稳定打开以后，再逐个恢复真正需要的插件，每恢复一个就检查启动和阅读。尤其留意会在启动时同步资料、扫描全库、自动改名或整理文件的功能。我也关闭了已安装的启动自动升级功能，方便在配置稳定时继续排查。
如果受限模式下仍然不停加载，就需要继续检查文件下载、可用空间和应用本身的异常，不能一直靠删插件猜原因。完全进不了设置时，先核对电脑端与云端的数据，再考虑恢复或重装。
我给三台设备分开了配置
我的 Mac Mini、MacBook Pro 和手机，使用同一份笔记，但分别读取自己的 Obsidian 配置目录：
| 设备 | 使用的配置目录 |
| --- | --- |
| Mac Mini | .obsidian |
| MacBook Pro | .obsidian-mbp |
| 手机 | .obsidian-mobile |
这样桌面端启用的插件、窗口布局，不必全部照搬到手机。手机先保留阅读、记录和实际用得上的功能，其他功能确认能稳定运行后再加。
在我当时的手机界面里，入口是：设置 → 文件与链接 → 高级 → 切换设置文件夹。把输入框里的 .obsidian 改成 .obsidian-mobile，再重启。官方英文名称是 Override config folder。新目录不会自动继承旧设置，旧配置也不会被删除。配置目录说明
我一开始就是按“覆盖配置文件夹”这个译名找，没找到。后来对照手机截图，才确认它叫“切换设置文件夹”。不同版本和翻译可能有差异；它下方的“重建仓库缓存”是另一项操作，不用为了切换配置去点它。
这些配置目录仍然可能被 iCloud 同步。分开目录只是让各设备读取各自的设置，能减少共用配置的相互影响；同一篇笔记被两端同时修改的风险，还需要另外处理。
iCloud 继续用，但先核对这几个地方
Obsidian 官方列出的 iCloud 适用设备包括 Mac、iPhone 和 iPad。我的这次记录也只覆盖苹果设备，不套用于 Windows。官方同步说明
先检查所有设备是否登录同一个 Apple 账户、开启了 iCloud Drive，并打开了同一个库。手机端的库应当位于：
iCloud Drive / Obsidian / 你的库名
这里的 Obsidian 应是 App 使用的专属文件夹。已有正常识别的库，不需要为了排查再建一套同名库。初次设置和路径检查，可以参考 FLO.W 的 iCloud 教程。
然后检查文件是否已经下载。Mac 使用 macOS 15 或更新版本时，可以在 Finder 中对 iCloud 里的 Obsidian 文件夹选择“保持下载”。旧系统的“优化 Mac 储存空间”影响整个 iCloud，调整前要考虑本机容量。
最后检查同一个库是否同时开着 iCloud、Obsidian Sync 或其他双向同步程序。先确认谁在同步哪一批文件，避免多个同步通道一起改同一个库。
我现在换设备接着写，会先在目标设备打开那篇笔记，确认上一台设备的最后一句已经出现。灵感则尽量新建独立笔记，避免手机、电脑都向同一个“今日速记”文件追加。
已经有副本，先比较内容
看到 笔记 (1).md 或带编号的文件，先保留。编号可能来自同步、插件或者人工复制，单看文件名不能判定原因。
我的库也检查出了疑似副本，处理时没有按名字批量删除。发现内容不同的版本，就把双方都留住，再核对差异。
如果你遇到的是一篇笔记冒出两个版本，可以按这个顺序处理：
- 暂停继续修改这篇笔记的程序和设备，把两个版本都复制到备份位置。
- 打开正文比较，找出各自独有的内容；不能只按“修改时间较新”选一个。
- 在确认要保留的版本里合并需要的段落，检查链接和附件。
- 到其他设备确认合并后的内容已经到达，再处理旧副本。
如果分不清哪份完整，继续保留两份。同步工具不能替你判断，哪一段才是你想留下来的内容。
怎么知道这次真的恢复了
我没有只看“App 能打开”。当时实际确认的是：
- 手机能看到测试笔记里的图片。
- 连续启动三次，没有再次反复加载。
- 手机把测试字段改成“正常”，两台 Mac 都收到了这次修改。
后续继续接入工作台，手机也有正常使用和新建笔记的反馈。这些能说明当前使用已经恢复，仍不足以证明今后永远不再出现冲突。
你可以新建一篇专门的“同步验收”笔记，放一句独有文字和一张图片。电脑写、手机确认收到；手机再补一句，电脑确认收到。接着关闭并重开几次，检查图片和正文。需要离线阅读的内容，先让它下载完成，再断网试着打开。
如果问题还在，记下是卡在下载、加载插件，还是打开具体笔记时出错，并保留发生时间和相关文件。下一轮排查就有了明确对象，不必每次都从重装整个库开始。
你可以把下面这段复制到一篇新笔记，作为这次排查的记录：
检查时间：
卡在哪一步：下载 / 插件加载 / 打开具体笔记
电脑写入的测试句：
手机收到：待检查
手机补写的测试句：
电脑收到：待检查
图片、重开后阅读：待检查
下载后离线阅读：待检查
我这次最有用的变化，是从“能打开就算修好”改成逐项确认：图片、启动、手机到电脑的回传。后面是否再出现副本，还要继续观察。
进阶选读：有自动程序，再检查写入方式
我这套库除了手工记笔记，还接了自动收件、资料同步和 AI 整理。这些程序也会改文件，所以我把自动程序对主库的写入统一放在 Mac Mini 执行。
手机和 MacBook 仍能正常写笔记。这项约定主要管自动程序：其他地方先准备候选，不各自直接覆盖主库里的同一份文件。
接入后的程序在写入前，会检查文件有没有被别人改过。例如，AI 读到一篇旧笔记，生成整理结果期间我又补了一段话，程序发现版本不同就暂停覆盖，把旧内容和新候选都留下来。
我们实际测试了这条保护：拿旧版本来写，被拒绝；重复执行同一个任务，没有重复创建内容。
本机程序之间还加了写入锁，让它们按顺序完成落盘。但这个锁只约束接入它的程序，iCloud 和普通手工编辑不会自动遵守。使用自动整理时，我仍会避开同时手改同一篇笔记。
没有自动脚本的读者，不需要为了用 iCloud 另外搭一套守卫。先做好配置分开、轮流编辑和备份，就能减少很多不必要的相互影响。
进阶选读：同时用 Git，再检查这一处
我的库还使用 Git 保存版本。这次把 Git 的内部数据目录迁到了 iCloud 之外，笔记正文继续留在原来的库里。频繁变化的 Git 索引、对象和锁文件，就不再随着笔记一起进入 iCloud。
同时，关闭了 Obsidian Git 的自动备份、拉取、推送及启动拉取，保留人工检查后的 Git 操作。
这里很容易混淆：.gitignore 只影响 Git，不会让 iCloud 忽略某个文件夹。
已经有历史仓库、多个工作目录或多台电脑运行 Git 的人，需要先备份，再检查迁移后的关联。我这次的 Git 目录指向主机本地位置，其他设备不能直接拿这个路径使用。本文不放一条通用迁移命令，也不建议删除 .git 来解决同步问题。没有用 Git，可以直接跳过这一项。
本文依据本人使用反馈、Codex 协助修复的记录与 Obsidian 官方文档整理，核对日期为2026年10月2日。文字由 AI 辅助整理；未把安全模式恢复等同于唯一根因已查明，也未将本次恢复当作长期零冲突保证。
本文为本人恢复经历，Codex辅助整理；图卡由AI生成，图示非真实界面截图。