sudo blkid是唯一可靠获取真实uuid的命令，因其直接读取文件系统superblock元数据，不依赖挂载状态、udev缓存或设备类型，对未格式化分区不伪造uuid，且能准确识别ext4/xfs/btrfs等各类文件系统。
直接用 sudo blkid，它读的是文件系统 superblock 元数据，不依赖挂载、不靠 udev 缓存，输出的就是真实 UUID —— 其他方法要么滞后、要么受限、要么只是映射快照。
为什么 blkid 是唯一可靠入口
UUID 是文件系统创建时写进 superblock 的属性，blkid 直接解析这个结构，所以：
- 不需要设备已挂载
- 不受热插拔后 udev 同步延迟影响
- 对未格式化分区（如裸 /dev/sdb1）不会伪造 UUID，而是干脆不显示该字段，避免误导
- 普通用户运行可能在部分 LVM 或加密设备上遇到 Permission denied，加 sudo 即可绕过，但多数物理/虚拟机本地分区无需提权就能查
常见错误现象：用 lsblk -f 看到某分区 UUID 为空，就以为“没 UUID”，其实只是它没被 udev 完整识别；而 blkid /dev/sdb1 一跑，UUID 就出来了——说明问题不在设备，而在 lsblk 的数据源。
blkid 的实用参数组合
别只敲 sudo blkid 看满屏输出，按需裁剪更高效：
- 查单个设备的纯 UUID 字符串（适合脚本）：sudo blkid -s UUID -o value /dev/nvme0n1p2，输出就是 d92fa769-e00f-4fd7-b6ed-ecf7224af7fa，无引号无空格
- 只关心 UUID 和文件系统类型：sudo blkid -o list -c /dev/null，禁用缓存，避免旧结果干扰
- 排除伪设备（如 loop、zram）：sudo blkid | grep -v "^/dev/loop\|^zram"
注意：blkid 不会告诉你设备是否健康，如果输出中某分区 UUID 明显是全 0 或格式异常（如少位数、含非法字符），大概率是文件系统损坏或未正确格式化，得先 sudo file -s /dev/sdb1 确认是否真有 ext4/xfs 等标识。
别把其他“看起来像 UUID”的东西当真
这些命令返回的内容容易混淆，但都不是文件系统层的真实 UUID：
- cat /sys/class/dmi/id/product_uuid：主板 SMBIOS UUID，虚拟机里常为默认值或全 0
- cat /etc/machine-id：systemd 生成的逻辑机器 ID，镜像克隆后会重复
- ls -l /dev/disk/by-uuid/：只是 udev 建的软链接目录，链接存在 ≠ 设备可用，刚改完 UUID 后这里可能还指向旧路径
- tune2fs -l /dev/sda1 | grep UUID：只对 ext 系列有效，xfs/btrfs 分区执行会报错或静默失败
最典型的坑：在自动化脚本里用 lsblk -f 提取 UUID，结果在某台新装的 ARM 服务器上漏掉两块 NVMe 分区——因为它的 udev 规则加载慢，lsblk 快照里还没来得及填 UUID 列，而 blkid 早已返回正确值。
真实 UUID 只存在于文件系统元数据里，blkid 是唯一能稳定触达它的工具；所有依赖符号链接、缓存或特定文件系统的替代方案，都只是妥协下的次选，用前务必确认场景是否容错。
