Linux系统UUID需分三类：一是SMBIOS UUID（用sudo dmidecode -t system | grep UUID或cat /sys/class/dmi/id/product_uuid获取），代表物理主板标识；二是systemd machine-id（cat /etc/machine-id），为逻辑系统ID；三是文件系统UUID（blkid查得），仅标识分区，非机器级标识。
Linux系统层面的“UUID”不是单指一个东西，得先分清你要的是硬件主板序列号、内核识别的系统UUID，还是 systemd 生成的逻辑机器ID——它们来源不同、用途不同、命令也完全不同。
查主板/固件层的系统UUID（SMBIOS UUID）
这是最接近“物理机器唯一标识”的值，由 BIOS/UEFI 固件写入，常用于资产管理和虚拟机绑定。但部分 OEM 或虚拟化平台（如 VMware、QEMU）可能填空或用默认值。
- 用
dmidecode读取（需 root）：sudo dmidecode -t system | grep UUID，输出形如UUID: 4C4C4544-004B-3910-804A-B6C04F423732 - 若权限受限或容器中无法运行
dmidecode，可尝试 sysfs 接口：cat /sys/class/dmi/id/product_uuid 2>/dev/null，失败则返回空 - 注意：KVM/QEMU 虚拟机默认 UUID 是随机生成的；VMware 可能显示
00000000-0000-0000-0000-000000000000，不代表异常
查 systemd 的 machine-id（逻辑系统ID）
这是当前系统实例的唯一标识，由 systemd-machine-id-setup 在首次启动时生成，存于 /etc/machine-id。它不反映硬件，但对服务发现、日志归集、容器编排很关键。
- 直接读取：
cat /etc/machine-id，输出是纯字符串，如1a2b3c4d5e6f78901234567890abcdef - 该文件必须存在且非空；若为空或缺失，
systemd启动会失败，需手动运行sudo systemd-machine-id-setup重建 - 克隆镜像后未重置会导致多台机器 ID 相同——这是常见运维事故点，别跳过这步
别把磁盘分区 UUID 当成系统 UUID
很多人搜“Linux 查系统 UUID”却执行了 blkid，结果看到一堆 /dev/sda1 的 UUID——那是文件系统的标识，和机器本身无关。混淆这两者会导致配置错误，比如在 cloud-init 或自动化部署脚本里错用。
-
blkid查的是块设备文件系统元数据里的 UUID，只对已格式化的分区有效 -
lsblk -f里显示的 UUID 列也是同一来源，不是机器级标识 - 如果你要写 fstab 或 grub 配置，需要的是分区 UUID；如果要做主机注册、license 绑定、集群节点识别，必须用
/sys/class/dmi/id/product_uuid或/etc/machine-id
验证是否真实唯一：优先看 dmi/id + machine-id 组合
单一字段都可能被伪造或复用：dmi UUID 在虚拟机里易重复，machine-id 在镜像克隆后会雷同。生产环境真正可靠的识别方式，是两者组合校验，或加上 MAC 地址哈希（如 ip link show up | grep ether | head -1 | awk '{print $2}' | sha256sum | cut -c1-32）。
实际部署中，最容易被忽略的是：没检查 /sys/class/dmi/id/product_uuid 是否可读（某些安全加固策略会禁用该接口），也没在克隆后重置 machine-id —— 这两个动作必须进标准初始化流程。
