blkid是最直接可靠的uuid查询方式，它读取文件系统superblock元数据，不依赖挂载状态或udev缓存，支持所有已格式化分区；输出含uuid=、type=、label=字段，适合人工查看与脚本解析，未显示uuid则表明尚未格式化。
blkid 是最直接、最可靠的方式，它读取文件系统 superblock 元数据，不依赖挂载、不依赖 udev 缓存，几乎所有已格式化分区都能正确返回真实 UUID。
blkid 查所有设备或单个分区
blkid 输出简洁、字段明确（UUID=、TYPE=、LABEL=），适合人工查看和脚本解析。
- 普通用户运行
blkid即可查大部分设备；若遇到Permission denied（常见于 LVM 或加密卷），加sudo即可 - 查单个分区更快更干净：
sudo blkid /dev/nvme0n1p2 - 脚本中要纯 UUID 字符串（无引号、无空格、无前缀）：
sudo blkid /dev/sdb1 -s UUID -o value - 如果输出里某设备没显示
UUID=字段，大概率是还没mkfs格式化过，file -s /dev/sdb1会返回data而非文件系统类型
/dev/disk/by-uuid/ 验证链接是否生效
这个目录不是“查 UUID”，而是验证“当前系统是否认可该 UUID 并能映射到设备”。
-
ls -l /dev/disk/by-uuid/显示的是符号链接：例如abcd1234-... -> ../../sdd4 - 链接存在 ≠ 设备可读 —— 若目标设备节点不存在、权限不足、或刚改过 UUID 尚未被 udev 重载，链接可能指向无效路径
- 启动时
/etc/fstab实际用的就是这个目录下的链接，所以这里缺失会导致挂载失败，哪怕blkid能扫出来
findfs 已知 UUID 反查设备路径
当你只有 UUID 字符串（比如从 /etc/fstab 里复制的），想快速定位它对应哪个物理分区，findfs 比 grep 扫 blkid 输出更准。
- 命令格式：
sudo findfs UUID=abcd1234-5678-efgh-9012-ijklmnopqrst - 成功时直接输出设备路径，如
/dev/sdd4；失败则返回非零退出码，适合写进自动化检查逻辑 - 它能处理多路径、LVM 等复杂场景，
blkid | grep在这类环境下容易漏匹配或误匹配
别依赖这些命令查 UUID
有些命令看似能出 UUID，但实际用途受限，容易误判：
-
tune2fs -l /dev/sda1 | grep UUID：只对 ext2/3/4 有效，xfs、btrfs、vfat、swap 分区直接报错或无输出 -
lsblk -f：UUID 列依赖 udev 数据，热插拔后可能延迟更新；对未挂载且无 LABEL 的分区，常为空白 -
udevadm info --name=/dev/sdb1 | grep ID_FS_UUID：查的是 udev 缓存值，不是实时读设备元数据；如果刚用tune2fs -U改过 UUID，这里可能滞后几秒甚至需要udevadm trigger
真正关键的点就一个：UUID 是文件系统层的属性，不是设备层的。裸设备、LVM PV、swap 分区、加密容器本身没有 UUID——只有在其上创建了 ext4/xfs/vfat 等文件系统后，blkid 才能读出来。别在没 mkfs 的分区上浪费时间调试 UUID 为啥不显示。
