最准最快查指定分区uuid用sudo blkid /dev/nvme0n1p2，它直读superblock、不依赖挂载或udev缓存；若无输出则大概率未格式化，可用file -s验证；纯uuid字符串加-s uuid -o value；/dev/disk/by-uuid/仅作映射验证，非源头；反查uuid对应设备用sudo findfs uuid=...。
直接用 blkid 查指定分区，最准最快
要查某一块盘上某个具体分区的 UUID（比如 /dev/nvme0n1p2），blkid 是唯一推荐的一线命令——它直接读 superblock，不依赖挂载、不靠 udev 缓存，结果就是文件系统里真实写死的那个值。
- 运行
sudo blkid /dev/nvme0n1p2，输出形如：/dev/nvme0n1p2: UUID="a1b2c3d4-5678-90ab-cdef-1234567890ab" TYPE="ext4" - 如果只要纯 UUID 字符串（方便脚本赋值），加
-s UUID -o value：sudo blkid /dev/nvme0n1p2 -s UUID -o value→ 输出就是a1b2c3d4-5678-90ab-cdef-1234567890ab，无引号无空格 - 没输出？不是权限问题，大概率是这个分区根本没格式化过：
file -s /dev/nvme0n1p2会返回data而不是ext4 filesystem data或XFS filesystem data
/dev/disk/by-uuid/ 目录只适合反查，别当源头用
这个目录本质是一堆软链接，名字是 UUID，指向设备路径。它反映的是 udev 上次扫描时的状态，不是实时读取设备内容——刚用 tune2fs -U 改完 UUID，这里可能延迟几秒甚至需要重启才更新。
- 查映射关系用：
ls -l /dev/disk/by-uuid/，看到类似a1b2c3d4-... -> ../../nvme0n1p2就说明当前内核认为这个 UUID 指向该设备 - 链接存在 ≠ 设备可用：目标设备节点可能已拔出、损坏或权限不足，
readlink -f /dev/disk/by-uuid/a1b2c3d4-...后再ls -l看目标是否存在 - 别用它来“生成”或“确认” UUID 是否有效——它不校验文件系统完整性，只做路径映射
已知 UUID 反查设备路径，用 findfs 最可靠
当你只有 UUID 字符串（比如从 /etc/fstab 里复制来的），想快速知道它对应哪个物理分区，findfs 是专为此设计的工具，比 grep 扫 blkid 输出更健壮，尤其在 LVM、多路径或设备名动态变化的环境里。
- 执行
sudo findfs UUID=a1b2c3d4-5678-90ab-cdef-1234567890ab，直接输出匹配的设备路径，例如/dev/nvme0n1p2 - 如果返回空且退出码非 0，说明系统当前没识别到该 UUID 对应的活跃分区——可能是已卸载、未激活、或文件系统损坏
- 注意：
findfs不支持 PARTUUID，只认文件系统 UUID；PARTUUID 需用findfs PARTUUID=...（但仅限 GPT 分区）
别碰 tune2fs 和 dumpe2fs 除非确定是 ext 系
这两个命令只对 ext2/3/4 有效，xfs、btrfs、vfat、swap 等统统不识别。强行运行要么报错，要么静默失败，容易让人误以为“没 UUID”。
-
tune2fs -l /dev/sda1 | grep UUID输出干净，适合脚本提取，但前提是/dev/sda1确实是 ext 系 -
dumpe2fs /dev/sda1 | grep UUID输出冗长，含大量调试信息，人工核对还行，不适合解析 - 执行时报
tune2fs: Bad magic number in super-block？立刻停手——这不是 ext 文件系统，换blkid
mkfs）就没有 UUID；而同一块盘重格式化一次，UUID 就彻底变了。所以看到设备名还在、但 UUID 不见了，第一反应不该是命令错了，而是得先确认文件系统是否还活着。
