用 dmesg | tail -20 查内核日志，出现 sdb/sdc 等设备名即识别成功；若无，可能是供电不足、接口松动、硬盘损坏或内核不支持。
怎么确认 Linux 识别到了移动硬盘
插上移动硬盘后，系统未必立刻“看见”它——不是所有设备都会自动弹出或挂载。先别急着 mount，得确认内核是否已探测到设备。
最直接的办法是看内核日志里有没有新设备的痕迹：
dmesg | tail -20
插拔瞬间执行这句，留意类似这样的输出：
[12345.678901] sd 2:0:0:0: [sdb] 976773168 512-byte logical blocks: (500 GB/465 GiB)
只要出现 sdb、sdc 这类名字（注意不是 sda，那是你主盘），说明识别成功。没看到？可能是供电不足（尤其 USB 集线器）、接口松动，或者硬盘本身损坏。
-
dmesg是实时日志，拔掉再重插一次更准 - 如果只看到
usb 2-1: new high-speed USB device却没后续sdX，大概率是硬盘控制器不被支持（比如某些 SMR 盘或 NTFS-only 的 OEM 移动硬盘） - 老内核（如 CentOS 7 默认的 3.10）对 USB 3.2 Gen2x2 或 NVMe 封装的移动 SSD 支持弱，升级内核可能解决
如何查到移动硬盘的设备名和分区表
识别到设备 ≠ 知道它分了几个区、用什么文件系统。不能靠猜 /dev/sdb1，得实锤。
推荐组合命令：
lsblk -f
它会列出所有块设备及其挂载点、文件系统类型、LABEL 和 UUID。重点看没挂载（MOUNTPOINT 为空）但有 FSTYPE（如 ntfs、exfat、ext4）的那几行，对应 NAME 列就是你要的设备路径，比如 sdb1。
- 如果
lsblk -f里整个sdb下面全是空的（FSTYPE、LABEL 全无），说明分区表损坏，或用了 Linux 不原生支持的格式（如 APFS、ReFS） -
sudo fdisk -l /dev/sdb可看更底层的分区结构，但需要 root 权限；普通用户用lsblk足够 - 某些移动硬盘出厂带隐藏恢复分区（如 Windows To Go 盘），会显示为
sdb1（EFI）、sdb2（恢复）、sdb3（主分区），别误删
挂载前必须检查文件系统兼容性
Linux 能“看到”设备，不代表能安全读写。NTFS 和 exFAT 最容易踩坑。
NTFS：默认只读，除非装了 ntfs-3g（现代发行版一般自带，但 Alpine、某些嵌入式镜像没有）；exFAT 需要 exfat-utils + fuse-exfat（Ubuntu 20.04+ 自带，CentOS 8+ 需手动开 EPEL）。
验证方法：
sudo file -s /dev/sdb1
输出含 NTFS 或 exFAT 字样后，再运行：
lsmod | grep -E "(ntfs|exfat)"
没输出？模块没加载，得先装驱动。
- Ubuntu/Debian：
sudo apt install ntfs-3g exfat-fuse exfat-utils - CentOS/RHEL 8+：
sudo dnf install ntfs-3g fuse-exfat - 挂载 NTFS 时加
-o rw,uid=1000,gid=1000,umask=022才能正常写入，否则权限全是 root - exFAT 不支持 Unix 权限，挂载时加
-o uid=1000,gid=1000防止新建文件属主为 root
安全挂载的最小操作链
别一上来就 mount /dev/sdb1 /mnt。临时挂载也要走标准流程，避免权限错乱或卸载失败。
四步闭环：
- 创建挂载点：
mkdir -p /mnt/usb（不要用/media下的路径，那些常被桌面环境占用） - 预检文件系统：
sudo fsck -n /dev/sdb1（只读检查，NTFS/exFAT 用sudo ntfsfix -d /dev/sdb1或sudo exfatfsck /dev/sdb1） - 执行挂载：
sudo mount -t auto /dev/sdb1 /mnt/usb（-t auto让系统自动推断类型，比不写更稳） - 验证可用性：
ls -l /mnt/usb看是否能列目录，touch /mnt/usb/test看是否可写（NTFS/exFAT 需提前配好 uid/gid）
卸载必须用 sudo umount /mnt/usb，别直接拔线。如果提示 target is busy，用 lsof +D /mnt/usb 查哪个进程占着，而不是强行 -l 或 -f。
真正麻烦的永远不是“能不能挂”，而是“挂完之后程序读取异常”——比如 Python 用 open() 读 NTFS 文件报 UnicodeDecodeError，其实是 Windows 创建的文件名含非 UTF-8 编码（如 GBK），这种问题不会在挂载阶段暴露，得等业务逻辑跑起来才崩。
