USB 设备插到 Linux 电脑上却毫无反应，最怕的不是情况难，而是不知道该从哪里查起。相比凭感觉猜，dmesg 给出的内核消息更适合作为第一手依据；再配合 lsusb、lsmod 和 BIOS 设置检查，通常就能把故障范围一步步缩小到连接、驱动、模块、系统兼容性或硬件本身。
下面按实际排查顺序整理一遍，重点不是把命令都跑一遍，而是看每一步能帮你排除什么情况、下一步该往哪里继续查。
先确认是不是硬件连接情况
在怀疑驱动和系统之前，先把最容易忽略、也最常见的情况排掉：接口、线缆和供电。
优先检查接口、线缆和插接状态
确认 USB 设备已经插紧，必要时重新插拔一次；如果没有反应，换一个 USB 端口再试，也可以换一根数据线。很多“系统识别失败”的表象，最后都只是接触不良、线缆损坏，或者前置接口供电不稳。
留意是否存在供电异常
如果设备偶尔亮一下又断开，或者插入后系统有短暂反应但很快消失，往往要考虑供电不足。尤其是移动硬盘、采集卡这类耗电更高的设备，最好优先尝试主板直连端口，减少中间转接环节。
系统到底有没有看到这台 USB 设备
这一步的目标很明确：先判断情况发生在“物理连接之后、驱动加载之前”的哪个阶段。
先用 lsusb 看设备是否出现在总线列表里
lsusb
如果设备能出现在列表中，说明系统至少已经在 USB 总线上看到了它，后续更应该关注驱动、协议支持或设备初始化阶段的情况。
如果设备完全没有出现在列表里，说明系统可能根本没有完成识别。这时就该回头继续检查接口、线缆、供电，或者去设备厂商官网、发行版仓库确认是否需要附加驱动支持。
用 dmesg 定位识别失败发生在哪一步
dmesg 是 USB 排障里最有价值的信息源之一，因为它记录的是内核真实看到的过程，而不是桌面环境是否弹出了提示。
过滤 USB 相关日志
dmesg | grep usb
执行后重点看设备插入前后的新增消息。常见线索包括：设备枚举失败、供电不足、协议不匹配，或者控制器层面的异常。相比“设备没反应”这种笼统现象，这些日志能直接告诉你故障点更靠近哪一层。
日志里通常能看到什么情况
如果日志提示枚举失败，通常要优先怀疑设备本身、连接质量或者兼容性情况；如果出现供电相关报错，就应优先检查端口供电和外设耗电；如果是协议或控制器提示异常，则需要继续往驱动、内核模块和 BIOS 设置方向排查。
检查 USB 相关内核模块是否正常加载
当设备在物理层面已经接入，但驱动链路没有正常工作时，内核模块状态就是下一个关键点。
查看当前已加载模块
lsmod
重点留意 USB 相关模块是否存在，例如 usb_storage、xhci_hcd 等。如果对应模块没有加载，设备即使接入，也可能无法被正常驱动。
必要时手动加载模块
modprobe usb_storage
modprobe xhci_hcd
手动加载后，可以重新插拔设备，再结合 dmesg 观察系统是否开始识别。如果加载模块时报错，那就说明情况可能已经不只是“没加载”，还涉及内核支持、模块依赖或版本兼容。
重启、更新系统，再看 BIOS 设置
前面的检查如果都没有直接定位情况，最后这几步往往能解决一批“配置没情况但状态不正常”的场景。
先排除临时性的模块或驱动状态异常
重启看起来朴素，但对 USB 识别异常确实有效。尤其是在内核模块状态紊乱、驱动初始化失败，或者设备热插拔后没有恢复正常时，重启常常能把情况带回可重复、可观察的状态。
更新系统和驱动版本
如果当前系统较旧，或者外设型号较新，内核版本过低就可能导致兼容性不足。可以先做系统更新，再检查设备制造商官网或发行版仓库是否提供更新驱动。
确认 BIOS 中的 USB 功能没有被关闭
部分主板会在 BIOS 中提供 USB 相关选项，例如 Legacy USB 支持或 XHCI Hand-off。如果这些功能被关闭，系统层面可能根本拿不到完整的 USB 控制器能力。进入 BIOS 检查相关选项是否启用，是最后一轮排查里不能省的一步。
什么时候该怀疑是硬件故障
如果硬件连接已经更换过、lsusb 看不到设备、dmesg 也没有有效识别信息，内核模块和 BIOS 设置也都正常，那么就要认真考虑硬件损坏的可能性。
这类故障可能出在 USB 控制器，也可能是设备本身已经失效。继续在系统层面反复折腾，收益通常不高；更现实的做法是换一台机器交叉测试，或者直接联系设备制造商的技术支持，尽快确认是不是外设硬件已经“罢工”。
