最准、最通用的是blkid命令，它内核级读取superblock，无需挂载即可输出真实uuid和文件系统类型；其他方法如tune2fs仅限ext系列、/dev/disk/by-uuid/依赖udev缓存、lsblk和udevadm可能滞后或不准确。
直接用 blkid 查指定设备最准
想看某一分区（比如 /dev/nvme0n1p2）的 UUID，就运行：blkid /dev/nvme0n1p2。它读的是文件系统 superblock 里的真实元数据，不依赖挂载、不靠 udev 缓存，输出干净可靠。
常见误区：没加设备路径直接跑 blkid 会列出所有块设备，容易漏看或混淆；而加了 -s UUID -o value（如 blkid -s UUID -o value /dev/sdb1）虽能输出纯字符串，但一旦分区没格式化，就什么也不返回——这不是命令失败，是它诚实地告诉你：这里没有文件系统，自然没有 UUID。
- 普通用户通常能查常规 SATA/NVMe 分区；LVM 或加密卷若提示
Permission denied，加sudo即可 - 如果
blkid /dev/sdc1完全没输出，先用file -s /dev/sdc1确认是否已格式化（返回data就说明还没mkfs） -
blkid不识别裸 LVM PV、未格式化的分区、BIOS RAID 成员盘——这些本就不该有 UUID
已知 UUID 反查设备名用 findfs
你手上有段 UUID 字符串（比如从 /etc/fstab 里复制的），想知道它对应哪个设备？findfs UUID=abcd1234-5678-efgh-9012-ijklmnopqrst 是最直接的解法。它比 grep 扫 blkid 输出更稳，尤其在多路径、LVM 或设备重命名场景下。
注意：findfs 返回的是第一个匹配的设备路径，如果有多个同 UUID 的分区（极罕见但可能，比如克隆镜像未重置 UUID），它只报一个；失败时直接退出非零码，适合写进检查脚本做断言。
- 必须带
UUID=前缀，不能只写字符串 - 不支持模糊匹配，大小写和连字符必须完全一致
- 如果返回空且退出码非 0，说明该 UUID 当前无对应可用设备（可能已拔出、损坏，或文件系统被破坏）
/dev/disk/by-uuid/ 只能验证映射，不能确认有效性
ls -l /dev/disk/by-uuid/ 能快速看到每个 UUID 指向哪个设备节点（如 abcd1234-... -> ../../nvme0n1p1），但它只是 udev 维护的符号链接缓存，不是实时读取磁盘内容。
这意味着：链接存在 ≠ 设备可读；链接指向 /dev/sdb2 ≠ /dev/sdb2 上的文件系统完好。刚用 tune2fs -U 改完 UUID，这里可能延迟几秒才更新；热插拔后若 udev 规则未触发，链接甚至可能缺失。
- 用
readlink -f /dev/disk/by-uuid/abcd1234-...可展开绝对路径，避免相对链接干扰 - 若链接目标是
/dev/loop0或/dev/mapper/xxx，说明它可能是 loop 设备或 LVM 逻辑卷，需进一步确认底层物理设备 - 这个目录不能用来生成或修改 UUID，纯只读用途
别用 tune2fs 或 dumpe2fs 查非 ext 分区
tune2fs -l /dev/sda1 | grep UUID 看起来简洁，但它只对 ext2/3/4 有效。xfs、btrfs、vfat、swap 分区执行会报错或静默无输出——tune2fs: Bad magic number in super-block 就是典型信号。
同样，dumpe2fs 输出冗长、含大量调试信息，仅适合人工核对 ext 系统；且它不支持 -o 类参数，没法干净提取字段，脚本里用容易出错。
- 判断是否 ext 系：先跑
blkid /dev/sda1，看TYPE=字段是不是ext4等 - 即使确认是 ext，也优先用
blkid——它更快、更轻量、输出格式统一 - CentOS 7.9 这类老系统里
tune2fs版本较旧，对某些 ext4 扩展属性可能解析不全，blkid更稳
