做了几期 Qcom USB Driver 的学习笔记前几篇分别梳理了 USB 基础协议、Linux USB 子系统的分层框架、Android 侧 USB 体系以及高通平台的控制器初始化流程。这次趁着手头一个实际项目收尾把整个知识体系再揉一遍重点放在代码路径、抓包实战和排查手法上。如果你也在啃高通平台 USB 驱动或者遇到枚举不稳定、adb 掉线、速率上不去这类问题这篇文章应该能省你不少事。1. 从整体框架到代码路径先把 USB 驱动的地图刻在脑子里1.1 软件栈的分层认知决定了你排查问题的效率USB 驱动的难点不在某个函数多难写而在链路太长。从应用层到物理线缆中间隔了七八层每一层都可能出问题你要是不清楚自己现在到底卡在哪一层排查起来就是无头苍蝇。以高通平台 Android 系统为例一条完整的数据通路大致长这样应用层通过 Android Framework 的 UsbManager 发起请求往下走是 UsbDeviceManager / UsbPortManager 这些系统服务再往下是 native 层的 usb_gadget / vbus 相关处理然后进入内核态依次经过 gadget 驱动层configfs、functionfs、adb、rndis、mtp 等、UDC 层UDC Core对应 DWC3 控制器驱动再到 PHY 层QUSB2 PHY 或 QMP USB3 PHY最后才是物理接口和线缆。这里有一个很容易忽略的点Android 上层往内核塞请求大部分时候并不是直接调用某个 ioctl而是通过 configfs 或者 sysfs 属性节点触发。比如切换 USB 功能从 MTP 切到 adb本质上就是往 /config/usb_gadget/g1/UDC 写值或者操作 functions 目录下的 symlink。所以排查问题的时候你首先得判断问题出在上层逻辑比如 UsbDeviceManager 状态没切过来还是出在内核 gadget 配置比如 function 没有正确 bind 到 UDC还是干脆就卡在 PHY 枚举阶段。这三类问题的外在表现很像都是插上没反应但排查路径完全不同。1.2 高通平台特有的分层实现DWC3 加自研 PHY 的组合拳高通平台和许多 SoC 厂商一样控制器 IP 用的 Synopsys DWC3但 PHY 部分是自己家的。这意味着你在内核里会看到两个相对独立却又紧密耦合的驱动模块。DWC3 控制器驱动位于 drivers/usb/dwc3/它同时支持 device 模式gadget和 host 模式host高通平台通过 device tree 里的 dr_mode 属性来决定工作在哪种模式。绝大多数手机场景下Type-C 口要兼顾充电、数据传输所以实际运行时会做角色动态切换这时候 DWC3 的 role switch 机制就派上用场了。PHY 这边就要看具体平台了。中低端平台一般用 QUSB2 PHYUSB2.0旗舰平台会加上 QMP USB3 PHYUSB3.0/3.1。PHY 驱动里做的最多的事情就是初始化眼图参数、校准阻抗、处理低速/全速/高速/超速的信号握手。真到了枚举不稳定或者速率不达标的时候八成要回 PHY 这边调参数。打个比方把 USB 通信比作两个人打电话DWC3 是电话交换机负责拨号、接通、挂断这些逻辑PHY 是电话线两端的调制解调器负责把数字信号变成能在物理线缆上传输的模拟信号。交换机坏了表现为拨号拨不出去调制解调器坏了表现为通了但听不清。你要是把听不清的问题拿到交换机的代码里找折腾一天也找不到病因。2. Qcom 平台 USB 驱动的源码地图与关键模块拆解2.1 内核源码树里你必须知道的那几个目录拿到一份高通 BSP 内核代码找 USB 驱动相关的源码认准这几个路径就够了。drivers/usb/gadget/ 是 gadget 框架和各个 function 的实现比如 f_adb.c 虽然不是 AOSP 主线文件但在高通的 BSP 里一定存在于某个 vendor 目录下。drivers/usb/dwc3/ 是控制器驱动核心dwc3.c、dwc3-msm.c、dwc3-qcom.c 这几个文件经常要打交道。drivers/phy/qcom/ 下面是高通 PHY 驱动qusb2-phy.c 和 qmp-phy.c 是重点。drivers/usb/core/ 则是 USB core 的实现hub、hcd、otg 这些子系统都在这里。厂商特有的代码一般不放主线。高通会在 vendor/qcom/proprietary/ 下维护一批私有模块比如 commonsys-intf/qiifa-fwk 这种从搜索热词里能看到类似路径专门用于 USB 相关的工厂测试、充电检测、音频扩展坞等功能的框架实现。如果你在主线内核里找不到某个功能去 vendor 目录下翻一翻往往就有答案。2.2 DWC3 控制器驱动核心从 dwc3_probe 到 role switchdwc3_probe 是控制器驱动的入口它负责读取 device tree 里的属性、初始化核心数据结构、注册中断、配置 gadget/host 相关的子设备。probe 流程走完不代表 USB 就能用它只是把基础设施搭好了真正让 USB 工作起来还得靠后续的枚举过程。在高通平台上dwc3-msm.c 或 dwc3-qcom.c 承担了平台相关的 glue 逻辑。它要处理时钟、电源、resetting 等 SoC 级别的资源还要监听 Type-C 状态变化收到状态通知后触发 role switch。举个例子插入一个 U 盘Type-C 协议栈检测到 Device 模式接入就会通过 extcon 或 typec class 的机制通知到 DWC3 驱动DWC3 再把控制器从 device 模式切成 host 模式然后开始 host 枚举流程。实际调试中role switch 是最容易出问题的环节之一。曾经遇到过一个 caseType-C 插入耳机转接线之后系统不识别log 里反复出现 extcon cable 状态切换的打印但 DWC3 就是没走到 host 模式。最后定位是 dwc3 的 workqueue 里处理 role switch 时被某个 mutex 卡住了而那个 mutex 被 probe 阶段的另一个线程持有。这类问题不读到内核日志根本看不出来所以遇到角色切换异常先打开 dwc3 的 debugfs 节点看一下当前 dr_mode 和 role 状态再对照内核日志找卡点。2.3 QUSB2/QMP PHY 驱动眼图参数和校准逻辑的学问PHY 驱动看起来代码量大但核心逻辑其实就三块初始化、校准、运行时电源管理。QUSB2 PHY 的初始化比较关键的是对 DP/DM 引脚上拉/下拉电阻的配置以及 HSDC 寄存器的设置这些直接决定设备能不能被主机正确识别为 Full-Speed 还是 High-Speed 设备。QMP USB3 PHY 则要额外处理高速差分信号的阻抗匹配以及 Rx/Tx 的均衡参数。校准部分一般由 bootloader 或内核里的 calibrate 接口完成校准结果会保存在 PHY 寄存器里电量管理相关的是在系统 suspend/resume 时切 PHY 的电源。如果你遇到设备插上电脑没反应但插在别的电脑上又能识别多半是 PHY 的线缆补偿参数不合适。高通在 device tree 里通过 qcom,qusb2-phy-init-seq 这样的属性传入一组寄存器初始化序列这个序列和 PCB 布局、线缆长度密切相关基本是平台工程师调出来的经验值。自己调的时候一次只调一个参数改完就测高速枚举、全速枚举、低功耗唤醒这几个场景千万别一次动一堆参数出了问题你根本不知道是谁引起的。2.4 Device Tree 中 USB 节点的关键配置项在 device tree 里配置 USB 节点有几个关键项一定不能写错。dr_mode 属性决定控制器工作在哪种模式可选值有 host、peripheral、otg。手机平台一般用 otg因为要支持插入 U 盘host也要支持连接电脑peripheral。如果配置成 host那 gadget 相关的功能就全部失效了比如 adb 传文件、MTP。utmi 和 hsic 相关的时钟配置或者 phy-names、phys 属性指定这个控制器关联到哪个 PHY 节点。高通平台会有类似 usb0 { qcom,usb2-phy qusb2_phy0; } 这种写法你看 dts 的时候先确认 phy 节点有没有被正确引用很多DWC3 probe 成功但枚举失败的问题其实就是 PHY 没配好。extcon 属性关联 Type-C 协处理器用于通知 USB 控制器当前 cable 状态。这个属性掉了角色切换就完全失灵。另外一个容易被忽略的是 vbus-supply 和 vbus-regulator它表示 VBUS 电源由哪个 regulator 控制。如果这个配错外接设备可能得到错误的供电电压直接导致枚举失败或反复 reset。定制板卡时这种问题在硬件验证阶段特别常见软件排查时要优先确认。3. Android 与底层驱动的协作机制从 UsbManager 到 configfs3.1 一次 USB 功能切换的完整调用链Android 上层发起 USB 功能切换比如在开发者选项里打开 USB 调试表面上只是 UI 上打了一个勾实际后台做了一堆事情。Settings 应用调用 UsbDeviceManager 的 setCurrentFunctions 方法这个方法通过 Binder 调用到 system_server 里的 UsbDeviceManagerService。UsbDeviceManagerService 接下来会通过 UEventObserver 监听内核上报的 USB 状态事件同时通过写 sysfs 节点或者 configfs 的方式命令内核 gadget 框架切换当前激活的 function。具体操作上内核的 configfs gadget 接口把每个 function 作为一个目录比如 /config/usb_gadget/g1/functions/ffs.adb 就代表 adb function。切换功能的实质就是修改这个目录下的 symlink把需要的 function 链接到 config 目录下然后重新绑定 UDC。这个流程对上层来说就是一个文件操作你看代码的时候会看到类似 echo ffs.adb /config/usb_gadget/g1/configs/b.1/ 之类的命令或者通过 libgadget 库封装后的调用来完成。这里面有个典型坑gadget 在切换 function 之前得先把 UDC 解绑否则新配置不生效。内核里做这个操作时会有一个简单的竞态问题——如果上层连续快速切换两个 function而内核还没来得及完成解绑就会出现配置残留或内核 crash。高版本的 Android 在上层做了串行化处理但在定制 ROM 里经常被裁剪掉导致偶现的切换失败。遇到这种问题不要改上层逻辑先去内核里把 UDC 的 bind/unbind 路径仔细看一遍。3.2 configfs 方式的 gadget 配置静态 vs 动态的差别如果只看 AOSP 或者某个厂商早期代码你可能会看到 legacy 的 android gadget 驱动它通过 platform_driver 的方式静态注册 adb、mtp、rndis 等功能。现在主流方案是 configfs 方式功能由用户在用户态动态组合灵活性高得多。configfs gadget 的核心概念是 UDC、Gadget、Config、Function。UDC 是控制器实例Gadget 是一个虚拟设备Config 是一个配置集合对应 USB 规范里的 Configuration DescriptorFunction 是具体功能比如 adb、MTP、RNDIS、UVC。把某个 Function 符号链接到某个 Config 下就相当于给这个配置添加了一个接口。实际排查时在设备上执行 ls /config/usb_gadget/ 就能看到当前有哪些 gadget 目录cat /config/usb_gadget/g1/UDC 可以看到是否已绑定到控制器。如果 UDC 文件内容是空的说明没有绑定成功gadget 等于白配。这比反复开机抓 log 要快得多。3.3 USB 状态事件的监听与上报内核态 USB 事件往用户态上报主要通道是 uevent。比如 USB 控制器检测到 VBUS 插入会往 usb 子系统发一个 uevent事件里包含 ACTIONADD、SUBSYSTEMusb 之类的键值对。Android 的 UsbPortManager 通过 Netlink 机制监听这些 uevent解析之后通知上层更新 UI 或者触发充电/OTG 逻辑。很多插上没反应的问题其实在 uevent 这一层就已经能看出端倪了。设备端可以通过 getevent -u 或者直接读 /dev/input 节点来确认内核到底有没有上报事件。如果在物理插入时 uevent 都没出现那问题和 Android 上层一点关系都没有问题出在硬件检测或内核早期初始化如果 uevent 正常但上层没反应那就要去查 UsbPortManager 和 UsbDeviceManager 的逻辑了。用这个思路你能快速把问题定位到软件栈的上半段还是下半段不至于在错误的方向上浪费时间。4. USB 抓包实战把协议从黑盒变成透明盒4.1 内核开启 usbmon抓包的环境准备到了深入排查的时候光看日志还不够得把 USB 总线上的原始数据抓下来分析。Linux 内核提供了 usbmon 子系统可以把 USB 总线上的 UR B 传输记录下来配合 Wireshark 就能做协议级别的分析。首先要确认内核有没有开启 usbmon 支持。标准内核一般默认是不开的需要配置 CONFIG_USB_MONy 或 m。如果是模块方式modprobe usbmon 之后 /sys/kernel/debug/usb/usbmon 目录下就会看到多个接口每个接口对应一个 USB 总线。手机这种 SoC 平台一般只有一个 USB 总线接口编号是 0。抓包前先 ls /sys/kernel/debug/usb/usbmon/ 确认接口存在然后用 tcpdump 或者 wireshark 直接读取 usbmon0 这个虚拟接口。这里有一个注意事项usbmon 在不同内核版本上的行为略有差异老内核可能需要在 debugfs 挂载后才能正常工作。挂载 debugfs 的命令是 mount -t debugfs none /sys/kernel/debug如果设备已经加密或者 selinux 限制严格可能需要先调整 selinux 策略或者直接在内核启动参数里加 disable 相关配置。实际项目里推荐顺手把这些配置放进用户的 debug 版本别在生产版本上留。4.2 用 Wireshark 分析枚举过程一个个包读懂 USB 协议抓包之后用 Wireshark 打开 pcap 文件你会看到 USB 总线上的 URB 记录包括 setup 包、数据包、状态包。分析枚举过程重点关注几个关键节点。设备接入后主机首先发一个复位信号Reset然后通过控制传输读取设备描述符Get Device Descriptor。设备返回的 18 字节描述符里包含了 bcdUSB、idVendor、idProduct 这些关键信息。如果这个阶段没有响应大概率是设备端的 D 上拉电阻有问题或者 PHY 还没完成初始化。接着主机发 Set Address 给设备分配地址设备收到后要在 2ms 内完成地址切换。如果地址设置失败常见原因是设备端 controller 状态机异常需要回看 dwc3 的中断处理有没有漏掉 Set Address 事件。再往后是完整读取设备描述符、配置描述符、字符串描述符等主机通过这些描述符决定加载哪个类驱动。如果配置描述符里的接口数和端点数和驱动预期不符比如某个功能需要两个中断端点但描述符里只写了 1 个就会导致驱动 probe 失败。我自己排查过一个异常一台设备的 adb 功能在 Windows 上能正常用但在 Linux 主机上却反复断开重连。抓包后发现设备返回的配置描述符长度比主机预期的多了一个字节导致 Linux 的 USB core 在解析时走到了错误的分支。这种问题光靠看代码很难发现抓包一眼就明白了。4.3 控制传输、批量传输和中断传输的抓包特征USB 总线上一共有四种传输类型。控制传输是双向的用于设备枚举和类请求特征是有 SETUP 阶段、DATA 阶段可选、STATUS 阶段。抓包时你会看到比较规整的三段式结构。如果 SETUP 包发出后没有 STATUS 包说明设备端没有正确完成请求处理。批量传输用于批量数据比如 U 盘读写、adb 传输大文件特征是多个 DATA 包连续出现没有严格的时序要求。中断传输用于键盘、鼠标这类需要周期性轮询的设备特征是固定的间隔时间。等时传输则用于音视频流对带宽要求高对丢包容忍度也高。在分析性能问题的时候批量传输最值得关注。比如 adb 传文件慢抓包看到发送窗口很小每次发几个包就停一下等 ACK那问题可能出在主机侧的调度策略或者设备侧的端点 FIFO 配置上。高通平台的 gadget 驱动里有相关配置来控制批量端点的突发长度burst调整这个参数往往能明显改善大文件传输速率。当然调这个参数也有讲究不能无脑调大因为 FIFO 大小是有限的增大了某个端点的 burst其他端点的 FIFO 就得让位得根据实际使用场景权衡。5. USB 转串口工具链调试手足之情的驱动分析5.1 常用的 USB-UART 芯片与内核驱动做嵌入式调试USB 转串口几乎是人手一个。常见的方案包括 FTDI 的 FT231X/FT232R、Silicon Labs 的 CP2102N/CP210x、WCH 的 CH340/CH341以及一些国产的小品牌。这些芯片的内核驱动各有特点。FTDI 系列对应内核驱动 ftdi_sio历史悠久兼容性做得最好但正因为历史包袱重不同批次芯片的 PID/VID 差异很大。如果插上设备后系统没有自动加载 ftdi_sio多半是设备的 PID/VID 不在驱动的 ID 表里需要手动 modprobe ftdi_sio vendor0x0403 product0x6001 强制加载或者把 PID 加到驱动的 id_table 里重新编译。CP2102N 对应驱动 cp210x这颗芯片的优点是厂家提供了非常完善的配置工具可以修改 VID/PID 和串口描述符在小批量定制设备里很常用。CH340 对应驱动 ch341国产芯片里性价比极高但稳定性在高温或长线缆场景下稍微差一点。选型时要关注的点如果只是调试用CH340 就够了便宜好买如果做产品集成FT232R 或 CP2102N 更稳妥驱动兼容性和固件成熟度都好很多。另外要注意很多 USB-UART 芯片有 3.3V 和 5V 电平版本接目标板之前务必确认电平匹配否则可能烧坏目标板的 GPIO。5.2 设备节点与权限管理别让 console 日志卡死在权限上USB-UART 芯片被内核识别后一般会创建 /dev/ttyUSB0 这样的设备节点。如果是调试串口Android 系统里可能还需要创建 /dev/ttyGS0 这类 gadget serial 节点两者对应不同模式——ttyUSB 是设备作为 USB host 去接外部串口转接器ttyGS 是设备作为 USB gadget 虚拟出一个串口给主机用。权限问题是日常踩坑的高发区。Android 设备默认只有 system 和 shell 用户有权限访问 /dev/ttyUSB*第三方应用想直接读写串口需要声明权限并在 ueventd.rc 里给节点加 chmod。常见做法是在 ueventd.rc 里写 /dev/ttyUSB0 0660 system dialout 这样的规则或者用 setprop 控制 SELinux 标签。如果你在用 adb shell 直接测试串口cat /dev/ttyUSB0 是能读到数据的但要想用 echo 往串口写数据得注意换行符和波特率设置。stty -F /dev/ttyUSB0 115200 设置波特率echo -ne AT\r /dev/ttyUSB0 发数据这是最朴素的测试方法。如果命令发出去了但设备没反应先确认是不是没有加 \r很多串口设备只认回车不认换行。5.3 高通平台集成 USB-UART 的经验心得在高通平台上集成 USB-UART 芯片有一个容易踩的坑是控制器时钟树。这类芯片的中断和数据传输依赖 USB 控制器时钟如果时钟没开启或者频率不对芯片可能偶尔工作偶尔不工作。排查方式是在设备树里确认 usb 节点的时钟配置然后在运行时读 clk_summary 看各个时钟的状态。另一个经验是在手机/平板上使用 USB-UART 芯片时注意和 DWC3 的 low-power 模式打架。当系统进入 deep idle 或者 suspend 状态时USB 控制器可能会断开连接导致串口工具掉线。这个问题要在 host 模式下规避通常的解法是配置 USB 控制器的 wakeup 事件在串口数据到达时唤醒系统。一旦遇到串口工具在系统睡死之后无法重连十有八九就是这个原因。6. 常见问题排查与避坑指南附现场实录6.1 枚举失败电脑上找不到设备或者反复提示无法识别这是最经典的故障按从硬件到软件的顺序排查。第一步确认线缆和数据线是否正常。USB 线看起来一样实际上只有带数据传输能力的线才能连上有些廉价线只接了两根电源线插上只能充电。用手头另一根已知正常的线替换一下能排除这个基础因素。第二步确认 VBUS 电压和 ID 引脚状态。如果是 Type-C 接口得查 CC 引脚有没有正确接上拉/下拉电阻。这一步可以通过读系统里的 typec 相关节点来确认比如 /sys/class/typec/port0/data_role 和 power_role 能看到当前角色。第三步看内核日志。dmesg | grep -i usb 或者 cat /sys/kernel/debug/usb/devices重点看设备有没有在被枚举时进入过复位状态。如果反复出现以 PID0 开头的记录说明主机侧一直在识别失败。第四步看 PHY 状态。高通平台可以读 /sys/kernel/debug/usb/ 下的 phy 相关调试节点确认 PHY 是否完成校准。如果校准没完成枚举大概率失败。6.2 枚举速度异常总是跑在 Full-Speed 而不是 High-Speed设备能被识别但速度不对比如 U 盘只能按 USB 1.1 的速度工作。这个问题的根源多半在 D 上拉电阻的配置上。USB 2.0 高速设备High-Speed在上电后会先被识别为 Full-Speed这时主机通过 chirp 信号来检测设备是否支持高速设备端收到 chirp 之后要主动发出 K-J 序列来应答。如果设备端的 PHY 对 chirp 信号的检测太灵敏或者太迟钝都会导致主机认为设备只是 Full-Speed 设备。高通平台的 QUSB2 PHY 里有专门的寄存器来控制 chirp 检测的阈值这些值一般在 dts 的 qcom,qusb2-phy-init-seq 里。遇到过很多次插上只有 Full-Speed 或者只有 12Mbps的问题调这个序列里的几项参数就好了。具体调哪几个值得看芯片手册里的 PHY 寄存器说明每个平台不一样不能照抄。6.3 adb 掉线数据线动不动就断开重连adb 掉线分两种一种是插着好好的突然 1ms 超时断开另一种是休眠唤醒之后 adb 服务恢复不了。前者的常见原因是 USB 信号完整性不好比如线缆过长、接触不良、PCB 布线没有做阻抗匹配。可以先用短一点的线试如果问题消失基本就是布线或者线缆质量的问题。软件层面可以调 PHY 的驱动强度或者均衡参数略微改善信号质量但这属于治标不治本。后者的常见原因是 USB 控制器的电源管理策略太激进。系统在 suspend 时把 USB 控制器的时钟关了唤醒后没有恢复完整导致 adb 数据链路断开。解决方向是调整 USB 相关的 autosuspend 参数或者修改 dwc3 的 resume 路径确保唤醒时 USB 管线完全重新初始化。很多团队在项目后期干脆直接关掉 USB 的 autosuspend代价是待机功耗略高但换来的是稳定性。6.4 常见问题速查表现象优先排查点关键日志/节点可能根因插上无任何反应VBUS/ID/CC 引脚dmesg | grep -i usb硬件通路或 PHY 未初始化枚举反复 reset线缆质量PHY 参数/sys/kernel/debug/usb/devices信号完整性差或 PHY 配置偏只能 Full-SpeedPHY chirp 配置PHY 调试节点QUSB2 init seq 错误adb 频繁掉线线缆、autosuspenddwc3 日志电源管理或信号问题功能切换不生效configfs 绑定状态/config/usb_gadget/g1/UDCUDC 未重新绑定串口工具乱码波特率、电平stty 配置硬件电平或入参错误host 模式 USB 识别不了extcon 状态/sys/class/typec/port0角色切换失败大文件传输慢端点 FIFO 配置usbmon 抓包批量端点 burst 不足6.5 调 PHY 参数的保守做法先备份再继续最后提醒一点调 PHY 寄存器参数时一定要先把当前的值完整记录下来。实际做法是写一个脚本把 QUSB2/QMP PHY 相关的寄存器全部 dump 到文件里改动一个参数就重新 dump 一次并对比差异。这样才能知道每一次改动具体影响了哪些寄存器出了问题可以立刻回退。稳妥起见一次只调一个参数并且每个参数只调一小步比如驱动强度先调 1 档测试一轮再决定下一步。切忌按照论坛里的经验一口气改好几十个寄存器值那种操作方式看着爽出了问题你连回退的基准都没有。另外如果条件允许在打磨 PHY 参数时用示波器观察 DP/DM 或 SS 差分信号的眼图比单纯靠设备是否枚举成功来判断要科学得多。哪怕是入门级的示波器能看到眼图开口情况调参效率都会提升很多。7. 写在最后分享几个我踩过的实战坑这一路做 Qcom USB 驱动学习最大的体会是USB 协议本身不难难的是整个链路太长任何一个环节的微小瑕疵都会被放大成设备用不了这种大问题。学驱动不能只看代码必须把协议、控制器、PHY、Android 框架这几块串起来理解再用抓包工具把理论和实际对上号。给刚开始接触这块的朋友一个建议在你手上的板子上把 usbmon、debugfs、configfs 这几个调试手段玩熟它们比任何文档都可靠。第一次抓包成功、第一次从原始数据里分析出枚举过程的那种成就感比看十篇博客都管用。最后再分享一个小技巧每次改完 USB 相关的 dts 或者内核配置编译烧录后不要急着跑业务测试先做一轮完整的 USB 枚举、插拔、角色切换、休眠唤醒压力测试。这些场景最容易暴露问题而且越早发现越好修。等这些问题清干净了再进入正常的业务开发流程你会发现自己省下了大量回过头来定位 bug 的时间。