macOS 灾后状态恢复：Keychain 重建、Syncthing 重配对、OneDrive 冲突处理
前提是系统已经能启动，基础软件已经重装，dotfiles 也已经重新部署。事故本身和根因链条在前一篇里写过，配置恢复在dotfiles 那篇里写过，这篇记录剩下的三块：
- Keychain 登录态与本地信任关系
- Syncthing 设备证书与配对关系
- OneDrive 冲突文件与版本收敛
这三块都是运行中积累的状态，不在 dotfiles 仓库里；没有单独备份时，需要逐项修复。
Keychain：不只是密码箱
~/Library 被删之后，Keychain 基本被清空，丢的不只是几个密码，还有整台 macOS 的一部分身份状态。
直接后果之一是 Apple ID 自动登出，iCloud 同步中断。系统反复要求重新登录，一批依赖 Keychain 凭证的服务也随之失去登录状态，需要重新授权。
1Password 只能补回我主动保存进去的那部分密码，补不回只存在于 Keychain 里的本地服务凭证。后者如果没有第二份副本，只能在下次使用时重新设置。
SSH 这一层也受影响。私钥文件从备份里恢复之后，git push 仍然不能直接回到事故前的体验，因为 SSH key 的 passphrase 缓存已经丢失，每次都会重新提示输入。后面我把 SSH key 重新加回 Keychain，这部分工作流才真正恢复。
Syncthing：与 10 台对端逐个重新握手
我的 Tailscale 网络里有 11 台设备，平时靠 Syncthing 在多台机器之间同步文件。事故之后，air 这台 MacBook Air 上的 Syncthing 配置和证书文件被删掉。Syncthing 识别的是设备 ID 和证书，不是机器名：同样叫 air，证书变了，在其他节点眼里就是另一台设备，别的机器上会显示成“未知设备”。
恢复没有捷径，只能在其余 10 台设备上逐个重新配对。大部分设备能通过 Tailscale 远程连上，不用逐台到场，但流程机械且耗时：
- 在一端接受新设备
- 在另一端确认共享文件夹
- 观察连接是否建立
- 核实同步是否正常
重新配对之后，还要逐个目录判断：哪些目录可以直接从其他设备补齐，哪些目录在事故和恢复过程中出现缺失，哪一端才是当前最完整、最可信的版本。
OneDrive：几百个带 (2) 的冲突文件
Home 目录被删之后，我一边从备份恢复，一边云端同步还在继续运行。本地恢复文件、云端旧版本、恢复过程中的中间状态在多个时间点交错，最后是大量带 (2) 后缀的副本文件散落在各个目录里。
冲突的来源至少有几类：
- 云端旧文件重新同步下来，与刚恢复的本地版本撞名
- 恢复过程中的中间文件先被同步上去，后续又和更新版本并存
- 本地和云端都认为自己是最新版本，客户端只能保守地各保留一份
处理顺序是：先停同步，再按目录比对来源，确认哪个版本保留，需要时手动合并，最后再恢复自动同步。顺序不能反：边同步边清理的话，客户端会继续依据尚未收敛的状态制造新的冲突，一边清理一边重新污染现场。每个目录都要重新判断哪个是旧的、哪个是新的、哪个只是恢复过程中的过渡产物、哪个版本已经被其他设备依赖。
事后改了什么
- 配置继续放 Git，这一层最容易恢复
- 密码和凭证不再只依赖系统当前的 Keychain 状态，关键内容要么在 1Password 里有副本，要么单独做 Keychain 导出
- Syncthing 的配置和证书额外备份，避免节点身份丢失后重新构建整张配对关系
- 对关键目录增加比 Time Machine 更明确的快照，避免同步盘在短时间内把错误版本快速传播
另外两个习惯也固定下来了：删除类命令先 dry-run，这已经从“应该做”变成硬规则；OneDrive 里的重要目录尽量开启版本历史，冲突未必能完全避免，但至少保留一个可回看的时间点。