FileVault仅加密启动宗卷（如“Macintosh HD”），不加密Recovery HD、EFI分区或固件，其解密依赖未加密的引导链；真正的引导安全需配合Secure Enclave或T2芯片的固件级防护（如安全启动、固件密码）实现双重保护。
FileVault 本身不加密或保护引导分区（如 Recovery HD 或 EFI 分区），它只加密启动宗卷中的用户数据和系统文件。真正的引导安全需配合固件级防护机制，而非 FileVault 单独完成。
FileVault 和引导分区的关系要分清
- FileVault 加密的是 APFS 宗卷（例如“Macintosh HD”）里的全部内容，包括 macOS 系统、应用、用户资料，但不包含 Recovery HD、EFI 分区或 Boot ROM 固件。
- Recovery HD 是一个独立的、未加密的宗卷，用于系统恢复、磁盘修复和 FileVault 解锁界面；它的存在是 FileVault 正常工作的前提，但自身不被加密。
- EFI 分区极小，存放启动加载器（boot.efi），也不受 FileVault 影响——它必须保持可读，否则 Mac 根本无法开机。
加固引导分区的关键是固件层控制
要防止他人通过外接介质启动、篡改恢复环境或绕过登录直接访问磁盘，必须启用硬件级引导锁：
-
Apple Silicon Mac：进入恢复模式 →「启动安全性设置」→
- 「安全启动」设为「完整」（验证所有启动组件签名）
- 「允许启动介质」设为「不允许」（禁用 USB/Thunderbolt 启动）
- 此设置由 Secure Enclave 强制执行，无法被软件绕过
-
Intel Mac（带 T2 芯片）：在恢复模式中打开「启动安全性实用工具」→
- 启用「固件密码」（阻止从外部设备启动、禁用恢复模式无密码访问）
- 建议同时开启 FileVault，形成“固件锁 + 数据锁”双重防护
⚠️ 注意：这两项设置均需管理员密码，且一旦启用，重置需物理接触设备（Apple Silicon）或输入固件密码（Intel/T2）。磁盘工具、终端命令或系统设置里任何操作都无法替代或削弱它们。
为什么不能靠 FileVault “加密引导分区”？
- 引导过程发生在操作系统加载前，FileVault 的解密逻辑依赖内核和驱动，而这些都在被加密的宗卷里——必须先有可信的、未加密的引导链（EFI → Recovery → 解密驱动）才能启动解密流程。
- 把 Recovery HD 也加密会导致无法解锁系统，形成死循环；苹果刻意将其保持明文，但通过签名验证+固件锁来保障其完整性。
额外建议：降低 Recovery HD 被滥用的风险
- 确保至少一个管理员账户设置了强密码（非空、非纯数字、禁用自动登录）——这是 Recovery HD 中 FileVault 解锁界面的唯一认证方式。
- 不要将恢复密钥存于 iCloud（尤其在多设备共用 Apple ID 时），优先使用离线手写保存的 24 或 28 位密钥。
- 定期检查 Recovery HD 是否完好：终端运行
diskutil list | grep "Recovery"，若缺失，需用恢复模式中的「重新安装 macOS」重建（不抹除数据）。
FileVault 是数据锁，不是启动锁；守住引导入口，得靠芯片级的安全配置。两者配合，才构成完整的设备失窃防护闭环。
