最准、最通用的是blkid命令，它内核级读取superblock，无需挂载即可输出真实uuid和文件系统类型；其他方法如tune2fs仅限ext系列、/dev/disk/by-uuid/依赖udev缓存、lsblk和udevadm可能滞后或不准确。
直接用 blkid 查最准，它读的是文件系统 superblock 里的真实值，不依赖挂载、不靠缓存，多数情况普通用户就能跑，不用加 sudo。
用 blkid 查指定分区的 UUID（推荐首选）
这是最直接、最可靠的方式。输出格式统一，字段明确，适合人工核对或脚本提取。
- 查单个设备：
blkid /dev/nvme0n1p2，输出形如/dev/nvme0n1p2: UUID="a1b2c3d4-..." TYPE="ext4" - 只取 UUID 字符串（无引号、无前缀）：
blkid -s UUID -o value /dev/sdb1，结果就是纯 UUID，比如a1b2c3d4-e5f6-7890-g1h2-i3j4k5l6m7n8 - 如果没输出或只有
PARTUUID没有UUID，说明该分区还没格式化（file -s /dev/sdb1会返回data），或者被mkswap、pvcreate等覆盖了文件系统头 - 部分 LVM 或加密设备可能报
Permission denied，这时加sudo blkid /dev/mapper/vg0-lv_root即可
用 lsblk -f 快速看 UUID + 挂载关系
适合你同时关心“这个 UUID 挂在哪了”“用的是什么文件系统”，但它的 UUID 列依赖 udev 数据，刚插上的设备可能延迟出现。
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- 运行
lsblk -f，看UUID和MOUNTPOINT两列对应关系 - 未挂载且没设
LABEL的分区，UUID列可能为空——这不是 bug，是 udev 还没完成识别 - swap 分区在
lsblk -f中通常不显示 UUID，但blkid会显示TYPE="swap"行
从 /dev/disk/by-uuid/ 反查设备路径
这个目录不是实时读设备，而是 udev 维护的符号链接缓存。它不能告诉你 UUID 是否有效，但能快速验证“这个 UUID 当前指向哪块盘”。
- 执行
ls -l /dev/disk/by-uuid/，看到类似abcd1234-... -> ../../sdd4 - 如果某个 UUID 链接目标是
../../dm-3或../../nvme0n1p1，说明映射正常；如果链接损坏或根本不存在，代表该设备当前未被内核识别（可能已拔出、故障或未初始化） - 刚用
tune2fs -U random改完 UUID，这里不会立刻更新，要等 udev 重载或重启后才同步
用 findfs 已知 UUID 反查设备名
当你只有 UUID 字符串（比如从 /etc/fstab 里抄来的），想确认它现在到底对应哪个设备，findfs 比 grep 扫 blkid 输出更稳。
- 运行
findfs UUID=abcd1234-5678-efgh-9012-ijklmnopqrst，直接输出匹配的设备路径，如/dev/sdd4 - 失败时返回非零退出码，适合写进自动化检查逻辑做断言
- 在多路径、LVM 或 RAID 场景下比手工
grep更可靠，因为它走的是内核设备树查找路径
真正容易被忽略的点是：UUID 是文件系统属性，不是设备物理标识。裸分区（没 mkfs）、LVM PV、swap、加密卷这些没有文件系统的载体，本身就没有 UUID —— blkid 不显示不是命令坏了，是它本来就没有。
