mkfs命令本身不提供“强制”语义，所谓“强制格式化”实为绕过已有文件系统检测、直接覆写元数据的操作；关键在于参数是否被对应后端工具识别——mkfs.ext4用-f而非-f，mkfs.xfs用-f而非-f，混用将报错或静默忽略；未卸载设备会导致ebusy错误，需用findmnt或lsof确认真实挂载状态；格式化成功不等于可用，须用dumpe2fs/xfs_info验证元数据，并检查内核模块是否加载。
mkfs 命令本身不提供“强制”语义，所谓“强制格式化”其实是绕过已有文件系统检测、直接覆写元数据的操作——它不是加个 flag 就万事大吉，而是取决于你用的命令和参数是否真能跳过校验。
误以为加 -f 或 -F 就安全，结果在 /dev/sda1 上跑了一次 mkfs.xfs -f，发现系统起不来——这种事真发生过。关键不在“怎么加参数”，而在“加给谁、为什么加、加了之后还缺什么”。
mkfs.ext4 -f 和 mkfs.ext4 -F 的区别必须分清
这两个参数作用完全不同，混用会失败或静默忽略：
-
mkfs.ext4 -f：无效参数，ext4 的mkfs.ext4不认-f，会报错invalid option -- 'f' -
mkfs.ext4 -F：这才是 ext4 的强制覆写开关，跳过“设备已有文件系统”的检查，直接重写 superblock 和 group descriptors - 而
mkfs.xfs -f才是 xfs 的强制开关；mkfs.xfs -F反而不存在 - 如果你用的是
mkfs -t ext4，它底层调用mkfs.ext4，但部分旧发行版（如 CentOS 7）不透传-F，建议直接用mkfs.ext4 -F
没卸载就跑 mkfs，99% 失败或内核 panic
Linux 内核会阻止对已挂载设备的格式化操作，不是命令拒绝执行，而是 mkfs 在 open() 阶段就会收到 EBUSY 错误。常见现象：
- 输出
/dev/sdb1 is apparently in use by the system（即使lsblk显示 MOUNTPOINT 为空） - 某些桌面环境自动挂载了 LVM 或 udisks2 管理的设备，
umount /dev/sdb1不生效，得查findmnt /dev/sdb1或lsof +D /run/media/xxx - 虚拟机里有时需额外运行
partprobe /dev/sdb让内核重新读取分区表，否则mkfs找不到/dev/sdb1 - 真正保险的做法：
sudo blockdev --flushbufs /dev/sdb1 && sudo umount /dev/sdb1
格式化完 mount 失败？多半是模块没加载或 UUID 没刷出来
成功打印 done 不代表文件系统可用。尤其 xfs 在某些内核（如部分云厂商定制版）默认不编译进内核，只作为模块存在：
- 挂载时报
wrong fs type, bad option, bad superblock，先试sudo modprobe xfs（ext4 同理试ext4） -
sudo blkid /dev/sdb1输出为空？说明格式化没写入成功，可能设备被占用、路径写错（比如写了/dev/sdb而不是/dev/sdb1），或磁盘有硬件坏道 -
sudo dumpe2fs -h /dev/sdb1 | head（ext4）或sudo xfs_info /dev/sdb1（xfs）能验证元数据结构是否完整，比单纯看blkid更准 - 别依赖设备名挂载——
/dev/sdb1下次重启可能变/dev/sdc1，blkid输出的 UUID 才是唯一标识
dd 清零 ≠ 格式化，但有时真得先 dd
当 mkfs 报 Device or resource busy 且确认已卸载，或者格式化后 mount 总提示 “can't read superblock”，大概率是旧文件系统残留元数据污染了关键扇区。这时需要底层清理：
-
sudo dd if=/dev/zero of=/dev/sdb1 bs=1M count=100：清空前 100MB，覆盖 superblock、inode table、journal 等区域（适用于 ext4/xfs） - U 盘或 SSD 上慎用全盘
dd if=/dev/zero——可能触发磨损均衡异常，甚至让控制器锁死 -
dd后必须重新分区（如果清的是整盘/dev/sdb）或至少运行partprobe，否则/dev/sdb1节点不重建 - 清完再跑
mkfs.ext4 -F，成功率显著提升；但注意：这步不可逆，且比单纯mkfs耗时得多
最易被忽略的一点：格式化命令执行中 Ctrl+C 并不会中止写入，它只是退出进程，底层 I/O 可能仍在刷盘。等几秒再查 blkid，否则容易误判失败。
