1. 为什么我用libusb做同步读写

先聊点正经的。搞USB设备开发的人应该都有这种感觉：Windows下写USB驱动，一套WDF/UMDF折腾下来，光环境配置就得耗掉半条命。Linux下倒是可以直接用usbfs，但接口不够友好。libusb这个库的出现，基本把用户态访问USB设备的门槛拉低了好几个量级——不需要写内核驱动，不需要处理复杂的权限体系，一个动态库搞定设备枚举、控制传输、批量传输、中断传输。

1.1 同步读写的本质是什么

很多刚接触libusb的朋友会问：同步读写到底是个什么概念？说白了就是阻塞式I/O。你调用一个libusb_bulk_transfer，数据没到或者没发完，这个函数就一直卡在那里，直到满足条件、超时或者出错才返回。与之对应的是异步模式，调用libusb_submit_transfer之后函数立刻返回，数据什么时候完成靠回调函数通知。

同步模式最大的特点就是代码逻辑非常直观。你把读数据当成一个普通函数调用：

int ret = libusb_bulk_transfer(handle, endpoint_in, buffer, length, &transferred, timeout); if (ret == 0) { // 数据拿到了，就在buffer里 }

没有回调，没有事件循环，没有状态机。这种模式特别适合那些"读一下数据、处理一下、再写一下结果"的交互式场景。比如我在调试某个采集设备时，上位机就是一问一答的节奏：发一条命令，等设备回一条响应，然后再发下一条。

1.2 什么时候该用同步模式

从我的实际经验来看，同步模式最适用的场景有两类。

一类是控制类操作。比如你要读写设备的寄存器、配置参数、切换工作模式，这种操作频率很低，每次就那么几十个字节，完全没必要启用异步那套复杂的机制。用同步控制传输，代码简洁，出错容易定位。

另一类是低到中等数据速率的批量通信。比如USB转串口的设备、数据采集卡、部分HID设备，数据速率通常在几MB/s以下，同步批量传输完全能扛住。我自己做过一个图像采集的小项目，PC端通过libusb从某成像模组拉数据，大概3~5MB/s的速率，同步读完全够用，CPU占用也很低。

但是，如果你的目标是USB3.0高速传输、每秒上百MB甚至GB级别的数据流，那同步模式基本就不合适了。异步模式配合多URB排队，才能把总线带宽真正压榨出来。同步模式下每次传输都要等待完成，URB的调度间隙、系统调用的开销都成了瓶颈。

1.3 libusb同步接口的设计哲学

用过libusb的人应该能感觉到，它的同步接口设计得非常“克制”。整个库的核心其实是异步机制，同步只是异步之上封装的一层方便接口。明白了这点，很多怪现象就能解释了。比如为什么步传输需要传入一个timeout参数？因为底层异步URB提交后，同步封装实际上是靠一个条件变量去等待完成信号，超时参数就是给这个等待过程兜底的。

再比如，为什么同步接口里还要返回一个transferred参数？因为USB传输不保证一次就能传完你指定的长度。对于批量传输，短包、错误重传、设备中途断开都可能导致实际传输字节数小于你请求的字节数。transferred就是用来告诉你到底传了多少，如果不判断它，代码就容易出隐蔽的bug。

理解了这层设计，你在用同步接口时就会本能地多留个心眼：返回的字节数可能不等于请求的字节数，超时参数一定要设，返回值一定要判断。这些都是后来踩坑总结出来的。

2. 环境准备与设备访问基础

2.1 依赖编译与库初始化

libusb本身跨平台，Windows、Linux、macOS都能用。我平时主要是在Linux环境下做嵌入式设备联调，安装很简单：

# Ubuntu/Debian sudo apt install libusb-1.0-0-dev # CentOS/RHEL sudo yum install libusbx-devel

Windows下的话，我建议直接从libusb官网下载编译好的二进制包，里面包含了dll、lib和头文件。用Visual Studio开发时，把libusb-1.0.lib链接进去，再把libusb-1.0.dll放到可执行文件目录下就行。需要注意x86和x64版本要跟你编译的目标平台一致，这个坑我看着不止一个人踩过。

代码里使用时，第一件事就是初始化：

#include <libusb-1.0/libusb.h> int main(void) { libusb_context *ctx = NULL; int ret = libusb_init(&ctx); if (ret != LIBUSB_SUCCESS) { fprintf(stderr, "libusb_init failed: %d\n", ret); return -1; } // ... 业务逻辑 ... libusb_exit(ctx); return 0; }

这里我给一个建议：初始化的时候传一个上下文指针的指针，而不是传NULL。libusb支持多上下文隔离，传NULL用的是默认上下文。在复杂的应用里，尤其是你同时操作多个业务模块时，各自维护一个上下文可以避免日志级别、调试信息互相干扰。我习惯给每个模块一个独立的libusb_context，互相不串味。

2.2 枚举设备与打开设备通道

设备枚举是入门libusb的第一道坎。USB设备不是像文件一样直接路径访问的，你得先拿到设备列表，再看每个设备的VID/PID是不是你要的。

libusb_device **list = NULL; ssize_t count = libusb_get_device_list(ctx, &list); for (ssize_t i = 0; i < count; i++) { libusb_device *device = list[i]; struct libusb_device_descriptor desc; int ret = libusb_get_device_descriptor(device, &desc); if (ret != LIBUSB_SUCCESS) continue; if (desc.idVendor == 0x1234 && desc.idProduct == 0x5678) { // 找到了匹配的设备 libusb_device_handle *handle = NULL; ret = libusb_open(device, &handle); if (ret != LIBUSB_SUCCESS) { fprintf(stderr, "device open failed\n"); } } } libusb_free_device_list(list, 1);

libusb_free_device_list的第二个参数是unref_devices，传1会同时释放每个设备的引用。如果你后面还要继续用某个libusb_device，这里就要传0，并且手动libusb_ref_device保引用。这里容易犯的错误就是：设备列表释放后继续用里面的device指针，导致use-after-free。实际开发中，我建议把匹配的设备直接libusb_ref_device引用起来，释放列表时传1，保持引用计数安全。

打开设备之后还需要做一件事：检查是否已经有内核驱动绑定了这个设备。Linux下如果设备被内核驱动占用，libusb是无法直接访问的，需要先卸载内核驱动：

if (libusb_kernel_driver_active(handle, 0)) { libusb_detach_kernel_driver(handle, 0); }

接口号0就是配置描述符里的接口编号。如果不止一个接口，就逐个检查。这一步经常有人忘，结果一打开设备就报LIBUSB_ERROR_BUSY，排查了半天才发现是内核驱动占着。

2.3 接口争夺与配置选择

拿到设备句柄并不代表你就可以直接读写数据了。USB设备的访问粒度是“接口”，你必须先声明对某个接口的所有权：

int ret = libusb_claim_interface(handle, 0); if (ret != LIBUSB_SUCCESS) { // 接口被占用，处理错误 }

我碰到过不少初学者在这里卡住：明明设备打开成功了，但一读写就报错，错误码是LIBUSB_ERROR_BUSY。原因就是没有claim_interface，或者别的进程已经占用了这个接口。

claim_interface本质是发一个SET_INTERFACE控制请求，把接口设置成你想要的状态。除了声明接口，有时还需要处理配置描述符里的多个配置。不过绝大多数设备只有一个配置，如果设备有多个配置，可以通过libusb_set_configuration切换，但注意这个操作会重置设备的全部状态，所有已声明接口都要重新声明，慎用。

还有一个细节：对于某些复合设备（比如带HID接口同时又带vendor specific接口的），你只声明需要的接口就够了，不用管其他接口。但如果设备只有一个接口同时承担读取和控制功能，那你就要注意接口的bAlternateSetting，某些设备需要切换不同的alternate setting才能拿到正确的端点配置。

3. 同步读写核心API实操拆解

3.1 bulk批量传输的读与写

批量传输是USB里最常用的数据传输方式。它的特点是：没有带宽保证，但数据可靠性极高，底层有CRC校验和重传机制。大文件传输、采集数据流都走的是bulk端点。

libusb对bulk传输提供了统一的同步接口：

int libusb_bulk_transfer( libusb_device_handle *dev_handle, unsigned char endpoint, unsigned char *data, int length, int *transferred, unsigned int timeout );

这里endpoint参数极其容易搞错。USB端点的方向是编码在地址里的：0x81表示端点1的IN方向（设备到主机），0x01表示端点1的OUT方向（主机到设备）。最高位为1代表IN，为0代表OUT。如果你把方向搞反了，最常见的报错就是LIBUSB_ERROR_PIPE，因为目标端点根本不存在或者方向不匹配。

我写过一套读写的代码，分享下核心部分：

int usb_bulk_read(libusb_device_handle *handle, uint8_t ep_in, uint8_t *buf, size_t len, unsigned int timeout_ms) { int transferred = 0; int ret = libusb_bulk_transfer(handle, ep_in, buf, len, &transferred, timeout_ms); if (ret == 0) { // 注意：transferred可能小于len，这是正常的 return transferred; } if (ret == LIBUSB_ERROR_TIMEOUT) { // 超时也算是一种“结果”，由上层决定处理策略 return transferred; // 或者返回-1，取决于你的协议 } return -1; } int usb_bulk_write(libusb_device_handle *handle, uint8_t ep_out, const uint8_t *buf, size_t len, unsigned int timeout_ms) { int transferred = 0; int ret = libusb_bulk_transfer(handle, ep_out, (uint8_t *)buf, len, &transferred, timeout_ms); if (ret == 0 && transferred == len) { return transferred; } return -1; }

写操作这里我严格要求了transferred == len。为什么？因为如果你要写100个字节，结果只写了50个字节就返回了，剩下的50个字节要不要重发？重发会不会跟上一次的数据重复？这些问题如果没有约定好，很容易造成协议状态错乱。我的经验是：上层逻辑在调用写接口之前就把数据完整组好，写的时候严格要求全写完，写不完就报错，由上层决定是否需要重试。

读操作那边，短读是常态。尤其当设备端的数据长度小于你传入的length时，设备会发送一个短包来结束传输。这个时候收到的数据就是有效数据，但小于你请求的长度。千万别因为一次没读够就当作错误处理，要看具体协议约定。

3.2 control控制传输的细节

控制传输用于获取设备信息、配置设备、发送厂商自定义命令。它由“setup阶段 + 数据阶段 + 状态阶段”组成，是USB协议里最复杂但也是最灵活的一种传输方式。

libusb的同步控制传输接口如下：

int libusb_control_transfer( libusb_device_handle *dev_handle, uint8_t request_type, uint8_t bRequest, uint16_t wValue, uint16_t wIndex, unsigned char *data, uint16_t wLength, unsigned int timeout );

request_type是最容易写错的参数。它由三部分组成：

• bit7：方向，0表示OUT（主机到设备），1表示IN（设备到主机）
• bit6~5：类型，00标准，01类，10厂商，11保留
• bit4~0：接收方，0设备，1接口，2端点，3其他

以常见的厂商自定义命令为例，你读设备某个寄存器时，request_type一般是0xC0（1010_0000 = 设备到主机的厂商请求，接收方是设备），写寄存器时是0x40（0100_0000 = 主机到设备的厂商请求）。

举个例子，往一个自定义设备发命令、读回状态：

// 发送命令，请求类型0x40，厂商命令0x01 uint8_t cmd[] = {0xAA, 0x55, 0x01, 0x00}; int ret = libusb_control_transfer(handle, 0x40, 0x01, 0x0000, 0x0000, cmd, sizeof(cmd), 1000); if (ret < 0) { fprintf(stderr, "control transfer failed: %d\n", ret); } // 读状态，请求类型0xC0，厂商命令0x02 uint8_t status[16] = {0}; ret = libusb_control_transfer(handle, 0xC0, 0x02, 0x0000, 0x0000, status, sizeof(status), 1000);

控制传输的wLength决定了你要传输的数据字节数，这个值必须和data数组的大小匹配。另外注意，控制传输的缓冲区长度上限一般只有64字节（高速设备是64，全速设备是8或16、32、64），别试图往里面塞几KB的数据。如果业务上确实需要大数据量，应该走bulk端点。

实际调试时，控制传输也是最容易出问题的地方。我见过很多人卡在设备不响应自定义命令上，结果一查发现是request_type的位没设置对，或者wIndex、wValue的理解跟设备固件不一致。这里有个实用技巧：先用USB分析仪或Wireshark配合抓包，看看上层发的"看见的USB请求"和固件期待的到底差在哪，这个问题多半立刻就清楚了。

3.3 interrupt中断传输与同步接口

中断传输名字听着像“硬件中断”，其实不是。USB的中断传输本质是“轮询”，主机在每个轮询周期内查询设备是否有数据要发。这种方式的延迟有上限，但带宽同样不高，适合鼠标、键盘、游戏手柄这类小数据量且对延迟敏感的设备。

libusb的同步中断传输接口用法和bulk几乎一样：

int libusb_interrupt_transfer( libusb_device_handle *dev_handle, unsigned char endpoint, unsigned char *data, int length, int *transferred, unsigned int timeout );

唯一要注意的是：中断端点在设备描述符里声明了bInterval（轮询间隔），这意味着哪怕设备立即准备好了数据，主机也要等到下一个轮询点才能把数据取走。所以如果你发现中断读有固定的延迟，别怀疑是libusb的问题，那是USB协议本身的机制。

我在HID设备调试中经常用到中断传输。HID类设备标准上就是用中断端点通信的，但HID规范本身又定义了Report Descriptor，一般推荐优先通过hidapi这种专用库访问，libusb也能做，但需要自己解析Report Descriptor并构造Set_Report/Get_Report请求，工作量偏大。如果你只是要访问一个普通的自定义HID设备，又不想引入更多依赖，直接用libusb也可以，但要做好心理准备，协议解析部分会比较繁琐。

4. 性能调优与稳定性设计

4.1 缓冲区大小与内存对齐

同步读写看起来简单，但性能差距可能很大。同样一个设备，用512字节缓冲区和用16KB缓冲区，吞吐量可能是天壤之别。

USB批量传输的默认行为是：每次请求的数据量越大，URB的调度效率越高。因为主机控制器在处理大传输时可以更好地利用总线空闲窗口。我实测过一个虚拟串口设备，128字节缓冲时吞吐量只有几百KB/s，换成4096字节后直接飙到2MB/s+。原因很简单，小缓冲区意味着要频繁提交URB，每次URB提交都有固定开销，这些开销总和起来就拖慢了吞吐。

所以我的建议是：读缓冲区至少设4KB起步，如果内存允许，16KB更好。写缓冲区则要根据你数据包的实际情况来定，如果单包就64字节，那没必要硬凑大缓冲区。

另外关于内存对齐，libusb官方文档里提到，为了提高性能，缓冲区建议按页大小对齐。Linux下页大小通常是4096，我一般直接用posix_memalign分配：

void *buf = NULL; size_t alignment = 4096; size_t size = 16384; posix_memalign(&buf, alignment, size);

不过说句实话，在现代操作系统上，堆分配器默认对齐都已经做得不错了，这个优化带来的收益很多时候感知不明显。但在嵌入式Linux上，尤其是内存管理比较精简的环境里，对齐分配还是值得保留的。

4.2 超时设计：同步阻塞下的防死策略

同步模式最大的风险是什么？就是阻塞。如果设备端出了问题，不回复数据，你的读操作就卡在那里。如果没有超时机制，整个程序可能就这么挂死了。

libusb同步接口的超时参数就是干这个的。我的经验有三条：

• 读操作超时不宜设太短。如果你的业务里设备可能会有不定时的主动上报，比如每5秒上报一条状态，你读一次就要允许至少比上报周期长的等待时间。设太短会导致频繁超时，白白消耗CPU。
• 写操作超时是保护机制。正常USB写操作是非常快的，如果它长时间不返回，往往意味着设备端没有及时从端点取走数据，FIFO满了，主机这边一直在重试。这个时候你应该尽快放弃，别死等。
• 超时返回值里带上实际传输的字节数。利用这个信息可以推断部分传输的情况。比如你要求读64字节，超时返回时transferred是32，说明设备已经发了32字节就停了，这可能就是你的数据边界，完全可以根据这32字节处理，而不是简单丢弃。

我自己惯用一个方式：把超时设计成可配置的，从配置文件或者命令行参数传入，而不是硬编码。调试时用大超时，稳定运行后慢慢收紧。这样在不同设备、不同场景下都能灵活应对，不用反复改代码重新编译。

4.3 多线程场景下的同步调用

libusb 1.0是线程安全的，不同线程可以使用同一个device_handle并发调用传输接口。不过这里有几点要特别注意：

• 同一端点的并发访问要加锁。两个线程同时对同一个ep_in调用libusb_bulk_transfer，一个线程读到的数据可能被另一个线程抢走，导致业务逻辑错乱。我建议用一个互斥锁保护每个端点的访问。
• 控制传输是全设备共享的通道。USB控制端点只有一个，所以对libusb_control_transfer的调用必须串行化。如果多个线程同时发控制请求，USB协议层面可能是有序的，但业务层无法保证请求的先后顺序符合预期。
• 不要在信号处理函数里调用libusb接口。信号处理函数的执行上下文极其受限，很多系统调用都不能做。如果信号来了你需要处理USB操作，正确的做法是在信号处理函数里设置一个标志，然后在主循环里检测这个标志再执行USB操作。

我实际做过一个采集系统，采集线程负责连续读数据，UI线程负责响应用户操作（比如切换采集模式），两个线程共享同一个设备句柄。当时因为控制请求并发的问题吃过亏，后来给所有控制传输包了一层锁，采集线程只管读，UI线程只管控制，互不干扰，问题就解决了。

4.4 热插拔处理与设备丢失恢复

USB设备最讨厌的地方就是热插拔。设备拔掉了，你的同步读写会怎样？libusb_bulk_transfer会返回LIBUSB_ERROR_NO_DEVICE。这个错误码意味着设备已经物理断开，你要做的不是重试，而是清理资源。

处理设备丢失的场景，我的做法是：

1. 在主循环里检测到LIBUSB_ERROR_NO_DEVICE。
2. 释放当前设备句柄：libusb_close(handle)。
3. 进入重枚举状态，周期性调用libusb_get_device_list查找目标设备。
4. 找到后重新打开、重新claim_interface。
5. 通知上层业务逻辑，让它们重新初始化自己的状态机。

有一件事要特别提醒：重新打开设备后，之前通过libusb_set_configuration设置的配置、alternate setting都会恢复默认值。如果你的业务依赖这些配置，重连逻辑里必须重新设置一遍。别问我怎么知道的，说多了都是泪。

libusb本身还提供了热插拔回调机制libusb_hotplug_register_callback，在Linux udev支持环境下可以自动感知设备插入拔出。不过这个回调依赖事件循环驱动，如果你不想引入事件循环，轮询枚举的方式也完全够用，看你的场景复杂度来选择。

5. 常见问题与排查避坑实录

5.1 典型错误码对照与处理

实际开发中，libusb返回的各种错误码是主要的排查依据，这里整理成速查表：

LIBUSB_ERROR_OVERFLOW这个错误值得多说一句。它是什么意思呢？设备在一个传输里发过来的数据比你的缓冲区还大，或者比端点的最大包大小还大，USB控制器直接检测到溢出。比如你分配了64字节缓冲，设备一次发了512字节。这个错误往往不是libusb的问题，而是设备和主机对数据长度的“预期”不一致。排查思路：先确认设备端描述符里声明的最大包长度是多少，再检查固件是否严格按照这个长度收发。

5.2 设备stall后的恢复处理

USB端点stall（停止）是一个很有意思的机制。设备在遇到无法处理的请求时会将端点置为stall状态，之后主机对该端点的所有传输都会返回LIBUSB_ERROR_PIPE。这是设备端的一种“拒绝服务”信号，协议层面上需要主机清除stall条件才能恢复。

对处于stall状态的端点，libusb提供了清除命令：

int libusb_clear_halt(libusb_device_handle *dev_handle, unsigned char endpoint);

注意这个操作需要传入端点的地址，并且包含方向位。例如0x81或0x01。清除halt操作会发送一个CLEAR_FEATURE控制请求（端点stall对应的feature是ENDPOINT_HALT），设备收到后会清除stall状态，之后端点恢复正常通信。

我遇到过的典型情况和解决步骤：

• 设备端收到无法解析的命令后，主动halt了端点。
• 主机下次读写返回LIBUSB_ERROR_PIPE。
• 先调用libusb_clear_halt恢复端点。
• 然后重发正确的命令。

这里有个小坑：如果设备端halt的是IN端点，你可能需要先读一次（即使超时）来清掉设备端的发送缓冲区，再执行clear_halt，然后再读。不同固件的处理逻辑不太一样，需要根据具体设备调整顺序。

5.3 与硬件固件联调的经验谈

libusb再怎么折腾也只是主机端的事，USB是主从架构，很多诡异问题其实是设备端固件导致的。我见过太多的"libusb读不到数据"最后定位到固件根本没有正确配置端点。

联调阶段，建议按这个顺序排查：

1. 先用lsusb -v（Linux）查看设备描述符，确认固件正确上报了VID/PID、配置描述符、接口描述符、端点描述符。
2. 确认端点地址和方向：固件里的端点号、IN/OUT方向和主机代码里的地址要严格一致。
3. 确认端点最大包大小。全速设备的bulk端点最大包可以是8、16、32、64字节，高速设备固定512字节，超速设备1024字节。主机和固件如果对不上，会出现数据错位或收不到完整包的情况。
4. 用libusb_control_transfer发一个厂商自定义命令验证设备的基本响应能力，不要一上来就跑大数据量bulk。
5. Windows下可以用Zadig替换驱动，或者直接用USB抓包工具看协议层的交互过程。

固件端还要注意一点：很多嵌入式MCU的USB栈在收到stall请求后会陷入一种"半死"状态。如果你是这种做法，主机端无论如何重试都没用，需要重新枚举设备或者复位MCU。所以固件设计时，对未知命令要有个兜底策略，比如忽略并继续正常运行，而不是halt端点。

5.4 Windows下的驱动与权限细节

Windows上libusb会遇到一个绕不开的问题：设备驱动。Windows默认不认识vendor specific的USB设备，需要安装一个WinUSB驱动或者用libusb的过滤器驱动。最省事的做法是使用Zadig工具，把目标设备的驱动替换为WinUSB。

但要注意，替换驱动是有副作用的。如果设备原来有官方驱动，替换后再装回去可能会很麻烦（Windows的驱动签名策略有时候会捣乱）。所以，WinUSB驱动直接用于开发调试阶段是没问题的，但产品化部署时还是得考虑正规的驱动签名和安装流程。

另外在Windows上，libusb_open有时会失败，提示LIBUSB_ERROR_NOT_SUPPORTED。这通常意味着设备当前加载的驱动不是WinUSB兼容驱动。去设备管理器里看驱动名称，确认是WinUSB或者libusb-win32，而不是某个厂商专有驱动。这个问题不需要怀疑libusb本身，libusb在用户态访问的底层就是WinUSB，如果驱动不对，它只能拒绝。

5.5 性能问题的定位思路

如果你觉得同步读写速度不理想，先别急着怪libusb。按照这个思路逐层排查：

• 先确认设备端的数据生产能力。用协议分析仪抓包，看看设备是不是本来就是"挤牙膏"式地慢慢发数据。
• 确认端点类型。如果是中断端点，bInterval就卡死了你的最大速率。中断传输的带宽上限是固定的，跟bulk不是一个量级。
• 确认USB协议版本和控制器模式。USB2.0高速的理论带宽是480Mbps，实际有效吞吐受协议开销影响，能跑到300Mbps左右就不错了。如果你挂在USB1.1 Hub下面，速度掉得离谱，那也正常。
• 确认缓冲区大小。我前面说过，缓冲区太小是性能杀手。
• 确认是否有别的进程同时占用USB总线。比如挂着U盘不仅影响磁盘性能，也会影响同一控制器下其他USB设备的总线时间。

一旦定位到瓶颈在主机端libusb这层，可以考虑切换到异步模式。同步模式做一轮传输，至少有一次系统调用、一次URB提交、一次等待，这个固定开销在低频交互场景下不是问题，但在高频大数据量场景下会明显拖后腿。异步模式配合多URB在飞行，才能把总线带宽利用率拉满。所以这里有个"二选一"的思路：数据量不大、交互频繁的，同步就行了；大数据量、追求极致带宽的，就该转异步了。

写在最后：一些个人经验

做USB开发这几年，我最大的体会是：libusb只是工具，真正难的是对USB协议本身的理解。很多问题之所以定位不到，是因为对设备端的行为预期不对。比如设备固件用的是中断端点，你非用bulk去读，那永远读不到数据；设备端把数据存在内部缓冲区里，如果你不按照它的协议发"开始传输"命令，它就永远不往外吐数据。这些不怪libusb，怪自己没把设备手册读明白。

还有一条经验是关于调试的。建议在开发初期就搭建一个USB抓包环境。Linux下可以用Wireshark加usbmon模块，Windows下可以用现有的USB分析软件。抓包能让你看到主机和设备之间所有USB请求的原始交互过程。有了这个视角，很多问题根本不需要猜，一眼就能看出是主机发错了请求，还是设备没有按预期响应。我后来无论做哪个项目，第一件事都是先把抓包环境准备好。

最后分享一个小技巧：如果你要调试libusb的行为，可以开启libusb自带的debug日志环境变量，在Linux下执行sudo export LIBUSB_DEBUG=4（或者Windows下设置环境变量），运行程序时关于URB的提交过程都会有详细输出，这对排查URB调度和错误码来源帮助很大。等你摸熟了libusb的脾气，这行命令能帮你快速定位是大方向错了，还是小细节没注意，省不少时间。