xiaoqi6pi112

---
name: 修复 iCloud 导致 Open/Save Panel 卡死
description: macOS 上 Open and Save Panel Service 因 iCloud (fileproviderd/bird) 死锁导致未响应的根治方案
type: reference
originSessionId: 172c3429-1740-4648-aa20-5888251efa6d
---
# 症状

- 任意 App 按 Cmd+O / Cmd+S 调出"打开/保存"面板时卡死、未响应
- 活动监视器里 `Open and Save Panel Service (XX)` 显示"未响应"
- 系统设置 → Apple 账户 也可能打不开（同样依赖 fileproviderd ）
- `brctl status`、`fileproviderctl dump`、`find ~/Library/Mobile Documents` 等命令本身会卡死

# 根本原因

Open/Save Panel 调用链：
`App → openAndSavePanelService → fileproviderd → bird (iCloud) / 其他 Provider → cloudd → 网络`

任何一环卡住整条链死锁。这次的元凶是用户目录下的 iCloud 状态文件损坏（ SQLite 索引坏了），导致 fileproviderd 持续死锁。

## 为什么"移走文件"能根治（核心原理）

死锁链路：
```
Cmd+O → openAndSavePanelService → fileproviderd
→ 读 FileProvider/CloudDocs 的 SQLite 状态库
→ SQLite 文件损坏，查询永远不返回
→ fileproviderd 内部线程死锁 → 整条调用链卡死
```

- **杀进程没用**：fileproviderd 重启后还是去读同一个坏文件,立刻又卡
- **重启整机没用**:坏文件还在磁盘上,开机就读
- **禁用扩展没用**:坏的是 fileproviderd 自己的状态库,不是扩展
- **安全模式没用**:安全模式不清用户域文件

把坏文件移走 → fileproviderd 重启后发现"没有状态文件" → 从零创建一个新的 → 从云端拉权威数据填充 → 一切正常。

## 四个关键文件的作用

| 文件/目录 | 作用 | 为什么是它坏 |
|---|---|---|
| `~/Library/Application Support/CloudDocs` | iCloud Drive 的**本地 SQLite 索引**，记录每个文件的同步状态、版本号、冲突信息 | 最大嫌疑。SQLite 文件断电、强杀进程、磁盘满都易损坏 |
| `~/Library/Application Support/FileProvider` | File Provider 框架的**用户级状态**，记录每个 Provider （ iCloud/OneDrive 等）的注册和同步状态 | 也是 SQLite ，同样易损 |
| `~/Library/Caches/CloudKit` | CloudKit 框架（ iCloud 底层协议）的本地缓存 | 缓存损坏会让 cloudd 一直在等不存在的数据 |
| `~/Library/Preferences/MobileMeAccounts.plist` | iCloud 账户在本机的配置 | 顺手清掉，避免账户层面的脏状态 |

## 为什么是"移走"不是"删掉"

如果新建的状态库也有问题（比如同步还是出错），还能把旧的移回来对比。**移走比删掉安全，是这类系统问题的通用做法**。确认稳定后（一般几小时到一天）再 `rm -rf` 删掉即可。

# 已排除但无效的方案

下面这些都试过没用，下次别浪费时间：
- `killall -9 fileproviderd bird cloudd` —— 进程会重启但马上又卡
- 整机重启 —— 状态文件损坏，重启后照样卡
- 安全模式启动 —— 还卡（证明不是第三方扩展问题）
- `pluginkit -e ignore` 禁用 iCloud / OneDrive 的 File Provider 扩展 —— 还卡
- 删除 `com.apple.appkit.xpc.openAndSavePanelService` 偏好 —— 该域根本不存在

# 诊断关键步骤（确认问题在用户域）

新建测试用户登录，按 Cmd+O：
- 新用户正常 → 100% 是当前用户 `~/Library/` 里损坏
- 新用户也卡 → 系统问题，需要重装 macOS

本次新用户正常，所以走下面的修复。

# 根治方案

移走当前用户的 iCloud / FileProvider 状态文件，让系统重建：

```bash
BACKUP=~/Desktop/icloud_backup_fix
mkdir -p "$BACKUP"

mv -v ~/Library/Preferences/MobileMeAccounts.plist "$BACKUP/"
mv -v ~/Library/Application\ Support/CloudDocs "$BACKUP/"
mv -v ~/Library/Application\ Support/FileProvider "$BACKUP/"
mv -v ~/Library/Caches/CloudKit "$BACKUP/"

sudo killall -9 fileproviderd bird cloudd
```

然后**注销当前账户重新登录**（不是关 App ，是注销）。

# 预期结果

- 注销重登后 Cmd+O 立即恢复正常
- iCloud 同步自动恢复（ Keychain 里凭据还在，通常不需要重新登录 Apple ID ）
- 云端 iCloud 文件全部完好
- 本地 `~/Desktop`、`~/Documents` 文件全部完好
- 备份目录里只是配置和缓存，确认稳定后可 `rm -rf` 删掉

# 重要注意事项

- 涉及到的命令在受 SIP 保护的目录上操作，需要终端有"完全磁盘访问权限"才能成功（否则 mv 会静默失败）
- 不要把 `BACKUP=~/Desktop/icloud_backup_$(date +%Y%m%d_%H%M%S)` 这种带时间戳的写法分两次粘贴执行，每次粘贴 `date` 会重新求值，导致 mkdir 和 mv 的目标路径不一致
- 路径中的空格必须转义：`~/Library/Application\ Support/...`
- 移走前用 `ls -la` 先确认文件存在，新版 macOS 有些 plist 不再存在（如 `com.apple.bird.plist`、`com.apple.CloudDocs.plist`、`com.apple.FileProvider.plist`），不存在的跳过即可

# 复发处理

直接重跑上面的命令块即可。这类 SQLite 状态损坏在 macOS 上偶发。

# 注意：备份目录的位置陷阱

如果当时开启了"桌面与文稿文件夹"同步,`~/Desktop` 实际指向 `~/Library/Mobile Documents/com~apple~CloudDocs/Desktop`,备份会同步到云端。本次操作后即使关掉了"桌面与文稿"同步,这些备份目录仍留在 iCloud 云盘的 Desktop 文件夹里,需要手动到 `~/Library/Mobile Documents/com~apple~CloudDocs/Desktop` 下删除,而不是 `~/Desktop`。

@chspy #9 已经过了， 那天全球性的崩溃事件

@d1g1tal0cean #5 慢

@d1g1tal0cean #5

@darksheen #3 美国也是吗？还是只有中国，这次是全球性事件吗？

@phithon #11 你试试现在你还进得去不？好像官网都进不去了

@ludan110 #1 这咋整？

@sitin #2 我是住宅 iP ，美国纽约的，这倒不可能