最可靠的方法是用blkid，它直接读取设备超级块识别文件系统类型（如ext4、xfs），支持未挂载设备和lvm/raid等抽象层；lsblk和df-t仅依赖挂载信息或udev数据，不可靠。
怎么一眼看出某个设备用的是什么文件系统
直接用 blkid 最可靠，它读取设备的超级块，能准确识别格式（比如 ext4、xfs、btrfs），连未挂载的盘也能查。
常见错误是只看 mount 输出——如果设备没挂载，就完全看不到；或者误信 /proc/mounts 里写的类型，其实那只是挂载时指定的，未必和实际一致。
-
blkid /dev/sdb1：查单个分区，输出带TYPE="ext4" -
blkid -o value -s TYPE /dev/nvme0n1p2：只输出文件系统名，适合脚本取值 - 注意：有些加密卷（如
LUKS）会显示TYPE="crypto_LUKS"，得先解锁才能看到内层文件系统
lsblk 显示的 FSTYPE 为什么有时候是空的
lsblk 的 FSTYPE 列其实是“尽力而为”：它优先从 /proc/mounts 和 udev 数据库里查，不主动读设备内容。所以未挂载、或 udev 信息过期时，这列就是空的。
它适合快速浏览拓扑结构，但不能替代 blkid 做格式确认。
-
lsblk -f：强制显示文件系统信息（仍可能为空） -
lsblk -T：显示 udev 的ID_FS_TYPE属性，本质和lsblk -f一样不可靠 - 遇到空
FSTYPE，别猜，直接上blkid /dev/xxx
df -T 输出的 file system 类型准不准
准，但仅限已挂载的文件系统。它显示的是内核实际使用的类型（比如 ext4 或 tmpfs），不是磁盘上存的元数据。
问题在于：如果挂载时用了 -t xfs 但实际是 ext4 分区，df -T 仍会报 xfs ——因为挂载参数覆盖了检测结果。这种错配虽少见，但在手动修复或旧脚本里可能出现。
-
df -T /home：查挂载点对应的类型 -
df -T不显示未挂载设备，也看不出 LVM 逻辑卷底层是什么 - 和
mount | grep /home对照看，能发现挂载参数是否显式指定了类型
遇到 LVM 或 RAID 设备怎么查真实文件系统
LVM 的逻辑卷（/dev/mapper/vg0-lv_root）和 md RAID（/dev/md0）本身不存文件系统，真正的格式在它们“指向”的物理设备上。但你不需要手动追到底层 —— blkid 能自动穿透这些抽象层。
唯一例外是加密卷嵌套（比如 LUKS on LVM），这时 blkid 只能看到外层 crypto_LUKS，必须先 cryptsetup open 才能查内层。
-
blkid /dev/mapper/vg0-lv_home：直接查逻辑卷，通常能出结果 -
blkid /dev/md0：RAID 设备同理，只要同步完成且无降级，就能识别 - 如果返回空或
crypto_LUKS，先运行lsblk看有没有crypt-前缀的子节点，再针对性解锁
真正容易被忽略的是：某些 USB 设备或 SD 卡在写入异常后，超级块可能损坏，blkid 会静默失败（不报错，但没输出）。这时候得结合 dmesg | tail 看内核是否报了 can't read superblock，再决定要不要用 e2fsck -n 或 xfs_info 辅助判断。
