macos磁盘加密异常需终端交叉验证：用fdesetup status -verbose查实时状态，diskutil apfs list看各卷locked/passphrase字段，sudo fdesetup list核对授权用户，外置盘须单独检测，恢复密钥缺失时立即导出新密钥。
MacOS 磁盘加密状态异常，往往不是“开或关”的简单问题，而是加密流程卡住、密钥未加载、恢复密钥失效或系统误判导致的假性异常。直接看系统设置里的开关状态容易误判，必须结合终端命令交叉验证真实状态。
确认 FileVault 实际运行状态
仅靠图形界面无法判断后台是否真在加密/解密，或是否已进入“锁定但未解锁”状态：
- 运行
fdesetup status -verbose：显示当前启用用户、恢复密钥托管状态、是否处于延迟启用（如新用户加入后需重启才生效） - 运行
diskutil apfs list | grep -A 5 "FileVault"：逐个查看每个 APFS 卷的实时加密层级——若某卷显示Locked: YES且Passphrase Required: YES，说明它尚未被系统自动解锁，这才是真正生效的加密保护 - 运行
sudo fdesetup list：列出所有已授权解锁该卷的用户账户，若返回空或缺失关键账户，可能造成登录后卷仍无法挂载
区分“加密中”是否异常停滞
加密进度卡在 99% 超过 2 小时，或 fdesetup status 显示 “Encryption in progress” 但磁盘 I/O 几乎为零，大概率是中断导致的逻辑卡死：
- 检查是否有后台任务冲突（如 Time Machine 正在备份、Spotlight 重建索引）
- 查看
pmset -g assertions是否存在阻止休眠/关机的长期锁（如PreventUserIdleSystemSleep），这类锁会干扰加密后台进程 - 若确认卡死，可尝试在恢复模式下执行
fdesetup disable强制退出加密流程，而非等待
外置卷与非启动卷常被忽略
系统设置中的 FileVault 仅控制启动卷，但合规要求通常涵盖所有含敏感数据的存储设备：
- 对外置 SSD 或加密 DMG，单独运行
diskutil info /Volumes/YourDrive | grep -E "(FileVault|Locked|Encryption)" - 若显示
FileVault: Yes但Locked: NO，说明它已被当前用户解锁，但未设为“登录时自动解锁”，属于策略缺口 - Time Machine 备份盘若启用加密，需检查其
.sparsebundle包内Info.plist中的AutoMount和Encryption字段，不能只看挂载状态
识别伪装开启状态（最危险的异常）
有些设备显示 “FileVault is On.”，实则恢复密钥已被清除或 iCloud 解锁未启用，一旦丢失密码将彻底无法访问：
- 运行
fdesetup haspersonalrecoverykey和fdesetup hasinstitutionalrecoverykey，确认至少一种密钥存在 - 若两者都返回
false，且未启用“允许我的 iCloud 帐户解锁我的磁盘”，则当前所谓“开启”毫无容灾能力 - 此时应立即导出新个人恢复密钥：
sudo fdesetup changerecovery -personal，并安全存档
不复杂但容易忽略
