diskutil list 显示所有物理磁盘及子分区的类型、大小、挂载点和标识符，但无法揭示 apfs 容器内卷的隶属关系；需用 diskutil apfs list 查看容器与卷的层级结构、角色及空间分布。
diskutil list 能看到什么分区结构
执行 diskutil list 是最直接的方式，它列出所有物理磁盘（disk0、disk1）和它们的子分区（如 disk0s1、disk0s2），包括每个分区的类型（APFS、EFI、Recovery）、大小、挂载点（如果已挂载）和标识符。
常见错误是只看第一层，忽略嵌套的 APFS 容器：比如 disk0s2 类型为 APFS Container，它本身不存文件，真正的卷（Volume）在它内部——这时候必须继续查容器内容。
- 终端里直接运行
diskutil list，别加-all或其他参数，默认输出最清晰 - 注意区分「磁盘」（
diskX）、「分区」（diskXsY）、「APFS 卷」（diskXsYsZ或独立显示为 Volume） - 如果某分区显示
Not mounted，不代表损坏，只是当前没挂载；APFS 容器下的卷可能自动挂载，也可能需要手动diskutil mount
diskutil apfs list 查容器与卷的关系
APFS 是 macOS 默认文件系统，一个容器（Container）可含多个卷（Volume），比如系统卷、数据卷、时间机器快照卷。仅靠 diskutil list 看不到这些卷之间的隶属关系，必须用 diskutil apfs list。
这个命令会按容器分组，明确列出每个容器的 UUID、大小、可用空间，以及其下所有卷的名称、角色（System、Data、Preboot）、挂载点和是否加密。
- 如果系统升级后出现两个同名卷（如 “Macintosh HD” 和 “Macintosh HD - Data”），
diskutil apfs list会清楚标出哪个是 System、哪个是 Data - 卷名带空格或特殊字符时，命令输出里会用引号包裹，复制时别漏掉
- 未解锁的加密卷不会出现在列表中，需先用
diskutil apfs unlockVolume才能查看
diskutil info 的精确诊断用途
当某个分区行为异常（比如无法挂载、报错 Could not mount disk），diskutil info 可查底层属性：文件系统类型、扇区大小、是否只读、UUID、最后检查时间等。比 list 更细，但不如 apfs list 展示逻辑结构。
关键点在于：它对任何设备标识符都有效，无论是 disk0、disk0s2 还是 APFS 卷的 UUID。
- 查某一分区是否启用 TRIM：
diskutil info disk0 | grep "TRIM Support" - 确认分区是否被标记为“恢复模式”：
diskutil info disk0s3中看Content (IOContent)是否为Apple_Boot - 遇到
Invalid argument错误时，先用diskutil info确认设备是否存在且可访问，避免对已卸载或损坏设备重复操作
容易被忽略的隐藏分区与权限问题
macOS 会创建多个隐藏分区（EFI、Recovery、VM、Preboot），它们通常不挂载、不显示在访达里，但 diskutil list 会列出。真正容易出问题的是权限和 SIP（系统完整性保护）限制：即使你是管理员，也无法直接写入 Recovery 或 Preboot 分区。
另一个陷阱是外接磁盘格式混用：USB 硬盘若用 Windows 格式化成 NTFS，diskutil list 显示正常，但 macOS 默认只读；而 exFAT 则无此限制，但不支持符号链接或 ACL。
- 不要尝试用
diskutil eraseVolume清除 Recovery 分区——它会被系统自动重建，但手动删可能触发启动异常 - 运行
diskutil命令无需sudo，除非涉及写操作（如unmount或erase）；误加sudo不影响读取类命令，但会养成危险习惯 - 某些第三方工具（如 Paragon、Tuxera）会添加自己的分区类型标识，
diskutil list中可能显示为未知类型，此时需结合diskutil info看原始Content字段判断
APFS 容器和卷的层级关系是核心复杂点，很多人卡在“为什么磁盘空间没满却提示空间不足”，答案往往藏在 diskutil apfs list 输出的各卷可用空间差异里。别跳过这一步。
