直接运行lsusb，若输出含“bus x device y: id xxxx:xxxx”行，说明内核已枚举识别；无新行但dmesg显示“new usb device”，则通信成功但id未收录；lsusb -t可查物理连接与真实速率，driver=(none)表明驱动未绑定。
lsusb 能立刻告诉你系统“看没看见”设备——只要输出里有 Bus X Device Y: ID xxxx:xxxx 这样的行，就说明内核已完成枚举，设备物理连接成功。它不依赖驱动加载，也不管设备有没有挂载成 /dev/sdb 或 /dev/ttyUSB0，只反映 USB 总线层的识别状态。
怎么确认设备是否被内核识别
直接运行 lsusb，等 2–3 秒再执行一次（刚插上可能有延迟）。如果看到类似这样的行：
Bus 001 Device 004: ID 0951:1665 Kingston Technology DataTraveler SE9
说明设备已被分配总线号和设备号，内核识别完成。ID 后面的 0951 是厂商 ID，1665 是产品 ID，这是硬件唯一标识，后续排查全靠它。
- 如果
lsusb完全没新行，但dmesg | tail -10显示new high-speed USB device，说明通信成功，只是 ID 没被/usr/share/hwdata/usb.ids收录，描述会是Unknown - 某些发行版（如 CentOS 7）默认不装
usbutils，运行lsusb报command not found，需先sudo yum install usbutils -
lsusb不显示/dev/ttyUSB0这类节点——那是usbserial模块加载后的事，跟lsusb是两层
怎么查清物理连接位置和真实速率
用 lsusb -t 看树状结构，它能暴露 USB Hub 级联、端口归属和实际协商速率。例如输出中某分支末尾标着 5000M，代表走的是 USB 3.x；标 480M 就是 USB 2.0。
- 一个标称 USB 3.0 的移动硬盘，如果插在 USB 2.0 Hub 下，
lsusb -t里它所在分支只会显示480M，性能被拖垮——光看设备本身 ID 发现不了这个问题 - 缩进层级对应物理连接：根 Hub → 下级 Hub → 终端设备。通过
|__ Port 2: Dev 5这类路径，能反推设备插在哪个物理口 - 如果某设备旁写着
Driver=(none)，说明内核没绑驱动，得查lsmod | grep或dmesg看模块是否加载
怎么快速定位某个特定设备
系统连了七八个 U 盘或摄像头时，全量 lsusb 输出太干扰。用 -d 或 -s 精准过滤：
-
lsusb -d 046d:0825：按厂商 ID:产品 ID 查罗技摄像头，ID 对得上就说明识别无误 -
lsusb -s 1:4：按总线号:设备号查，其中1:4来自lsusb输出第一列，不是设备文件路径 - 想看更底层参数（比如供电能力、协议版本），用
usb-devices，它按段落组织输出，找Spd=、Driver=、Lev=字段最直接
为什么 lsusb 看得见但设备不能用
lsusb 只管“连上了没”，不管“能不能干活”。常见断点在后面几层：
- U 盘插着但没挂载？
lsblk或findmnt才管这事，lsusb不负责 -
/dev/ttyUSB0没生成？检查lsmod | grep -E "(usbserial|ch341|cp210x|ftdi_sio)"，缺模块就sudo modprobe补上 - 设备被识别但权限不够？普通用户默认不能读
/dev/bus/usb/X/Y，得加 udev 规则或加入plugdev组 - 虚拟机里
lsusb -t可能只显示VMware, Inc. Virtual USB Hub，真实拓扑被抽象掉了，得去宿主机查
真正卡住的地方往往不在 lsusb 输出里，而在它之后的驱动绑定、模块加载、udev 规则、内核日志这几步——别只盯着那一行 ID xxxx:xxxx 看。
