如何查看 macOS 存储的物理驱动器映射-Mac OS-PHP中文网

如何查看 macos 存储的物理驱动器映射

要查看 macOS 存储的物理驱动器映射，关键不是找“盘符”或图形界面里看到的卷名（比如“Macintosh HD”），而是看清物理磁盘 → 分区/容器 → 逻辑卷这一整条链路。系统用的是设备标识符（如 disk0、disk0s1）和 APFS 容器结构，而非 Windows 那样的驱动器字母。

用 `diskutil list` 看清物理磁盘与分区拓扑

这是第一步，也是最基础的快照式总览：

打开终端，运行：
```
diskutil list
```
输出中你会看到：
- 所有识别到的物理设备（disk0 是内置 SSD，disk2 可能是 USB 盘）；
- 每个设备下的分区（disk0s1、disk0s2……），包括隐藏的 EFI、Recovery、Preboot；
- APFS 容器（类型为 Apple_APFS）及其下展开的卷（如 Macintosh HD、Macintosh HD - Data）。
  ⚠️ 注意：未挂载的分区、恢复卷、甚至断电后未弹出的外接盘，只要系统能识别，都会列在这里。EFI 分区不会挂载，所以你在访达里看不到它——但它就在 diskutil list 里。

用 `diskutil apfs list` 理清 APFS 容器内卷的归属关系

APFS 把传统“分区”升级为“容器 + 卷”，一个容器可容纳多个角色不同的卷。只看 diskutil list 容易误以为 Macintosh HD - Data 是独立分区，其实它只是容器里的一个逻辑卷。

运行：
```
diskutil apfs list
```
输出是缩进树状结构，例如：
```
Container disk1 (753.9 GB)  
  └─ Volume Macintosh HD (12.4 GB) 【System】 mounted at /  
  └─ Volume Macintosh HD - Data (698.2 GB) 【Data】 mounted at /System/Volumes/Data  
  └─ Volume Preboot (127.5 MB) 【Preboot】 mounted at /System/Volumes/Preboot  
  └─ Volume Recovery (1.2 GB) 【Recovery】 mounted at /System/Volumes/Recovery  
```
这能让你一眼确认：

macOS Automator Services
部署和使用军舰的 macOS Automator 自动化服务集合。包含 5 个实用工作流：PDF转JPG、PNG重命名并转JPG、图像拼接、解压RAR、顺序命名图像文件。一键安装所有服务到 ~/Library/Services/ 目录。使用场景：(1) "安装我的自动化服务"，(2) "部署所有 Automato...

下载
哪个卷是系统根、哪个是数据区、是否分离；
各卷是否已挂载（若显示 Not Mounted，说明当前不可访问）；
它们共同属于哪个容器（如 disk1），而该容器又落在哪块物理盘上（回看 diskutil list 中 disk1 对应的物理设备）。

用 `diskutil info` 查单个设备的物理连接协议与健康状态

想知道某块盘到底是 NVMe、USB 还是 Thunderbolt，以及它是否健康，得查具体设备：

先从 diskutil list 或 df -h 中找到目标设备节点，比如 /dev/disk0；
再运行：
```
diskutil info disk0
```
关键字段包括：
- Protocol: 显示 NVMe、PCIe、USB 或 Thunderbolt；
- S.M.A.R.T. Status: Verified 表示健康，Failing 则需警惕；
- Device Tree Path: 能看出是否走 PCIe 总线或经 USB 桥接；
- APFS Container Reference: 若是 APFS 容器，会显示其容器 ID，方便和 diskutil apfs list 对应。

必要时交叉验证物理接口真实路径

有些设备标称雷电，实际被降级成 USB（常见于某些硬盘盒）：

查雷电链路：

system_profiler SPTHunderboltDataType | grep -A 5 -B 2 "Device Name\|Speed"

查 USB 设备详情：
```
system_profiler SPUSBDataType | grep -A 3 -B 1 "Product Name\|Speed"
```
如果同一设备在两个报告中都出现，优先以 SPTHunderboltDataType 为准——它反映的是控制器直连路径，比 diskutil info 的 Protocol 更底层、更可信。

不复杂但容易忽略：物理驱动器映射不是静态的，热插拔、睡眠唤醒、系统更新后都可能变化。每次排查前，先运行 diskutil list 获取最新快照，再逐层向下深挖。