debug这东西入门时觉得是玄学写多了才知道全是逻辑。我最近把一段时间的调试记录翻出来整理发现很多经验根本不挑语言、不挑芯片哪都能用上于是决定把这些东西写成笔记算是对自己的一场复盘。这篇主要讲我这段时间跟debug打交道时的真实经过覆盖了IDE调试快捷键、Java接口调试、远程调试、单片机看门狗、CCS启动会话、芯片平台的调试串口这些场景也穿插了不少现成的配置和命令。无论你是刚学会写程序的新手还是已经踩过几轮坑的嵌入式/后端开发里面某些内容应该都能直接拿去用。1. 调试思路的底层逻辑1.1 先回答三个问题再碰代码接到一个bug我的第一反应不是马上打开编辑器瞎找而是先逼自己回答三个问题数据有没有到达这里程序的执行路径走的是哪条分支错误信息和正常情况差在哪这三个问题回答清楚了调试就成功了一半。你可以把整个程序想象成一条从上往下的水管bug是某个接头在漏水。最高效的排查不是把整条管子挖开看而是从中间掐一个口如果水能到中间说明上游基本是通的问题在下游继续在下方二分如果水根本到不了中间就往上游查。这就是我一直说的二分定位。以前我调一个Java接口慢把整个链路从头读一遍浪费一下午后来直接在Controller入口打一个日志、Service出口打一个日志看时间差一下子就把慢的那段圈出来了。二分定位的好处是每一步都让搜索空间减半尤其在大型工程里比逐行读代码可靠得多。配合Git提交记录还可以再提高一层用git bisect把引入bug的提交定位出来这个我在自己项目里试过多次属于“真香”工具。1.2 日志和断点怎么选才不浪费时间很多人纠结调试用日志还是断点我自己的标准很简单能停下来看状态的用断点没法停下来、或者一停就把现场搞坏的用日志。断点适合看变量、看调用堆栈、试条件逻辑日志适合看趋势、看频率、看多线程或多设备之间的时序。还有一类是断言也就是assert。断言不是给用户看的是开发期用来约束“这里不可能发生”的条件的。比如解析完一份报文后断言缓冲区长度必须等于报文头长度一旦不等直接崩溃早崩溃永远比带病运行强。我以前调一个数据解析问题就是因为挪用了一个字节没发现程序一直跑数据全错又找不到加了断言三分钟就现形了。日志也不是越多越好。我见过同事把串口日志调到每秒上百行结果看门狗一复位真正有用的前几条日志早被冲走了。正经做法是在关键路径留少量稳定的日志点细节日志单独用开关控制必要时再打开。嵌入式上尤其明显串口速度快不了日志写得满屏飞你反而看不清问题。1.3 调试前的环境检查清单我后来养成一个习惯任何调试开始前先花30秒过一遍环境把这五个最基础的东西确认掉编译配置是不是Debug模式优化等级是不是被开到了O2或O3符号表有没有生成调试端口或者烧录器、网络端口有没有监听程序有没有真的跑起来还是死在更早的地方。这些听起来很傻却能省掉一大半“假bug”。举个最典型的例子O2优化下一个局部变量可能被放进寄存器断点打上去IDE告诉你“No source available”或者变量值怎么都看不到。这时候不是代码逻辑错了是优化把那个变量优化掉了。把优化等级降到O0或者Og再看问题基本都会消失。在STM32的MDK工程里把优化从-O2调到-O0重编一次导致的现象我遇到不下五次。还有一个常见情况IDE调试时连的是远程容器里的服务改了代码没编译、或者镜像没重新加载你看到的还全是旧代码。所以调试前把“我改的东西有没有真正生效”这个问题放最前面比调一堆快捷键更管用。2. 常用调试工具的实操细节2.1 把IDEA的调试快捷键改成自己的肌肉记忆后端开发有一半时间泡在IDEA里Debug的快捷键值得花点时间调成自己顺手的样子。默认配置里F8是Step OverF7是Step IntoF9是ContinueShiftF8是Step Out。真正让效率起飞的是这几个CtrlAltF9也就是Force Run to Cursor能无视中间所有断点直接跑到光标处适合跳过一大段无关逻辑F9配合断点的条件设置能做到只在满足条件时停下来。改快捷键的位置在Settings - Keymap搜索Debugger Actions把Force Run to Cursor映射成自己方便按的键。我把Drop Frame也就是丢弃当前栈帧也绑定了一个顺手键这个功能在调试时非常有用当你已经在错误分支里走深了不用重新跑一遍直接把当前调用帧丢掉回到上一帧重新执行相当于时光倒流。不过要注意JVM不能做到真正的“修改历史”这个操作本质是让当前帧重新被调用但很多排查场景下已经够用。还有一个细节IDEA支持直接在Debugger面板里拖动调用栈的帧拖到你想看的帧上查看当时的变量和上下文。这个操作并不广为人知但在排查“变量在哪个流程里被改掉”这种问题时它比在代码里一次次打断点更快。建议有IDEA的同学现在就试试断点命中后在Debugger窗口找到调用栈列表点击上方任意一帧右侧立刻会显示那一帧的局部变量。2.2 IDLE的调试功能很多人没认真用过Python入门时用的IDLE其实自带调试器。很多人只知道按F5运行不知道顶部菜单的Debug - Debugger可以打开一个Debug Control窗口运行模式会变成单步执行。你可以在代码窗口里右键选择Set Breakpoint然后点击运行按钮程序执行到断点时会停下来左侧可以看到当前作用域的变量名和值。但说实话IDLE的调试器体验比较简陋单步、进出栈、查看表达式这些操作都很别扭。如果你只是写脚本不如直接用Python自带的pdbpython -m pdb script.py。进入pdb后b 行号设断点c继续执行到断点n执行下一行s进入函数p 表达式打印变量。我平时排查几个百行的小脚本pdb够用且零依赖比在IDLE菜单里找半天快得多。还有一个IDLE常见坑从IDLE启动调试后如果发现断点不生效先检查是不是忘了在Debug菜单里打开Debugger开关另一个坑是IDLE的Shell窗口和调试窗口同时存在时Print输出有时会延迟刷新让人误以为程序卡住了。实际上程序早跑完了刷新跟不上的情况更多。2.3 VSCode里用Keil5工程怎么把调试跑起来很多人习惯在Keil里写STM32但代码看到VSCode里更舒服于是想在VSCode里顺带把调试也做掉。这个需求我实现过核心是在VSCode里装cortex-debug插件让VSCode直接接管调试器然后通过J-Link或ST-Link连接目标板。如果你用的是J-Linkcortex-debug支持直接调JLinkGDBServer用ST-Link则通常配合openocd或pyOCD。launch.json配置大致是这样{ version: 0.2.0, configurations: [ { name: Cortex Debug, type: cortex-debug, request: launch, servertype: jlink, device: STM32F407VG, interface: swd, executable: ${workspaceFolder}/build/project.elf, runToMain: true } ] }这里executable指向的是编译生成的ELF文件必须含有DWARF调试信息也就是编译时要开启-g。如果你还沿用Keil生成的.hex或者.bin那只能烧录、不能源码级调试。如果Keil用的是ARMCC编译器生成的.axf本质也是ELF格式同样可以填进去使用建议先设置一个带调试信息的构建产物再拿cortex-debug调。对比一下两种常见方式Keil自带调试器配置简单但界面相对封闭无法和代码编辑器集成VSCode加cortex-debug能看完整调用栈、寄存器、外设寄存器但多一层工具链配置刚开始容易挂在daemon启动上。如果你只想要个能看的调试环境先从Keil跑通再说标的工程比较大、又不想被编辑器限定就值得花半小时把cortex-debug配起来。3. 接口调试和远程调试的实战记录3.1 想调试某个Java接口断点别只打在类上很多Java项目里Controller接口只有一行直接调用Service实现。你想在接口定义上打断点IDEA能正常命中实现类这个用法是支持的在接口方法行号右侧打一个断点运行到对应实现时同样会停下来。好处是业务接口多实现类时不用一个个去实现类里找位置。更常用的是条件断点。右键断点在Condition一栏输入表达式比如userId.equals(test)或者count 10。条件满足时才会触发调试数据量大时能省大量等待时间。我调过一个批量任务上万条记录逐条处理只有在某条特殊记录报错条件断点让我直接跳过其余九千多条一次命中。还有一个动态代理的坑得单独提醒。Spring项目里大部分Service都有AOP代理断点打在接口实现类上有时会出现出乎意料的跳转比如对象被CGLIB包装调用栈里多出几个lambda和内部类。这时候不要去跟代理层的每一步直接在实现方法体第一行打普通断点配合IDEA的Smart Step Into也就是ShiftF7选择真正的方法体调用效率会高不少。3.2 IDEA远程调试的完整配置过程远程调试的典型场景是代码在本地服务跑到一台测试机或容器里出了问题你在本地没法看现场。Java远程调试的原理很简单JVM通过JDWP也就是Java Debug Wire Protocol暴露一个调试端口IDEA作为Debugger连上去两边必须使用同一套源码。配置分两步。第一步服务端启动参数加一行java -agentlib:jdwptransportdt_socket,servery,suspendn,address*:5005 -jar app.jarsuspendn表示JVM启动后立刻正常运行等待调试器随时连接如果改成suspendyJVM会一直挂起直到调试器连接才继续适合调试启动阶段的问题。第二步在IDEA里打开Run/Debug Configurations新建Remote JVM Debug填入Host和Port选择项目对应的源码模块点Debug连接。连接成功后本地打断点、加条件断点、看变量都跟本地一样。但要注意远程调试的耗时更长因为每个变量值都要从远端传输过来在热点代码上频繁单步会非常卡。我的习惯是先加日志或条件断点缩小范围最后再用单步精确定位。另外还有几个安全层面的细节JDWP端口不要用默认的5005换一个高位端口服务端运行在公网时绝对不要开JDWP否则等于把调试后门暴露在网络上。3.3 远程调试报fatal error in native method后的排查有段时间我在一个老项目中做远程调试IDEA控制台突然弹出fatal error in native method第一反应不是JDWP配置错了而是JVM里的native代码出事了。这种错误通常意味着某个JNI调用崩溃、本地内存被写坏或者某个so/dll与当前JDK版本不匹配。排查思路有固定套路先去启动目录找hs_err_pid*.log文件JVM崩溃时会自动写下来。打开后重点看栈顶找到崩溃发生在哪个native库的哪个符号里再对照这个库是什么时候打的、用的是哪个JDK的jni.h头文件。绝大多数情况下重新用当前JDK版本的头文件编译一次native库就解决了。如果崩溃点刚好在执行一段JNI回调时还要怀疑对象引用管理是不是用GetPrimitiveArrayCritical之后忘了Release或者把JNIEnv*跨线程保存了。远程调试只是把现场暴露得更清楚一些真正的根因基本都在这些经典JNI问题上。4. 嵌入式调试高频坑看门狗、CCS与内核调试4.1 单片机debug一半就重启最先查看门狗在STM32上调试时最让人抓狂的现象是程序跑到断点停住还没看两眼板子自己复位了。原因在于CPU停下来了但看门狗计时器还在继续计数超时后触发硬件复位。有一次我排查一个UART数据错乱的问题在中断服务函数里设了断点程序每次进中断都会停在断点上然后没几秒板子重启数据完全没法分析。当时我还以为代码里有什么变量被野指针改了查了好久后来才想到是独立看门狗IWDG没关。Debug模式下CPU挂起IWDG的计数器照样走超时就咬着牙把整个芯片复位了。怎么判定是不是看门狗复位可以在启动时读一次复位状态寄存器STM32F4上是RCC-CSR里面有一位IWDGRSTF。这个标志置位就八成像看门狗了。把复位源编码打印到串口是我在嵌入式上最常用的一步诊断手段。4.2 Keil STM32调试阶段停掉看门狗的三步做法最彻底的办法不是注释喂狗代码而是让调试器在CPU停止的时候把看门狗时钟同时停掉。STM32在DBGMCU模块里提供了对应的控制位具体做法分三步。第一步在初始化代码里加入DBGMCU配置void dbg_disable_watchdog_in_debug(void) { DBGMCU-CR | DBGMCU_IWDG_STOP | DBGMCU_WWDG_STOP; }第二步确认这条路只在Debug版做Release版别带这个配置。可以在编译宏DEBUG下包一层#ifdef DEBUG dbg_disable_watchdog_in_debug(); #endif第三步在Keil的Debug选项卡里打开“Run to main()”并确保这段配置在执行用户业务代码前完成。如果只是临时调一次也可以在Keil的寄存器窗口里手动把DBGMCU-CR对应的WWDG_STOP位和IWDG_STOP位置1。更省事的做法是让调试器在连接后执行一段初始化脚本但我个人觉得把配置写进C代码里最直观也方便以后查阅。补充一句实际项目中看门狗是防跑飞的最后一道防线调试时禁用可以发布时一定要基于Release配置重新编译确认。我曾经见过同事把调试用的宏直接带到了生产烧录固件里结果板上WWDG全程不工作产品在强干扰环境下频繁死机这种事属于典型的“调试便利性挤掉了产品可靠性”。4.3 STM32F4的sys debug代码到底在哪里有同学在搜“stm32f4 sys debug代码实现在哪里”我第一次也找错过地方。STM32F4的嵌入式调试支持其实是分两层的一层是Cortex-M4内核自带的CoreDebug、DWT、ITM、BPU这些调试组件它们位于ARM内核内部寄存器地址在0xE000EDF0往后另一层是芯片厂商加的DBGMCU模块用来控制时钟、外设和低功耗模式中的调试行为寄存器挂在总线域上。如果你要找系统级的调试代码一般用ST的HAL库时搜dbgmcu相关API用标准外设库时关注DBGMCU_Config和DBGMCU_APB1PeriphConfig。比如想让调试器在睡眠模式时仍能连接需要配置DBGMCU-CR里的低功耗位想让SysTick在停驻时继续计数同样要去DBGMCU找。另外我想单独说一个很实用的工具DWT的周期计数器。它几乎不用初始化就能测代码耗时在嵌入式上排查一个函数是不是太慢非常方便。启用方式是CoreDebug-DEMCR | CoreDebug_DEMCR_TRCENA_Msk; DWT-CYCCNT 0; DWT-CTRL | DWT_CTRL_CYCCNTENA_Msk;然后在测量点读两次DWT-CYCCNT差值除以主频就是耗时。它不依赖任何IDE的调试器算是“用内核自己的能力做轻量级性能分析”非常适合嵌入式场景。4.4 CCS启动debug卡在icepick_c_0的排查记录TI的CCS在启动调试时会先创建调试会话再对目标器件做初始化和连接。日志输出里常见到starting ccs debug session...: initializing:icepick_c_0如果停在这一行不动说明目标芯片的调试访问接口没有正确握手。我遇到过的原因和解决思路如下第一目标板没上电或复位键被按着Debug会话无法建立先确认电源指示灯和复位时序正常。第二JTAG链上可能接了不止一个器件要确认CCS的Device配置里选对了目标和连接方式SBW、JTAG还是cJTAG。第三调试接口信号质量不好比如杜邦线过长尝试把JTAG时钟频率从默认值调低一半经常能解决。第四如果使用了外部仿真器检查驱动版本和固件版本是否匹配。这类“卡在初始化”的问题本质是调试器到芯片之间那条链路没打通。排查顺序永远是从物理连接出发再到软件配置最后才怀疑芯片本身。千万别一上来就反复擦除Flash因为擦除本身也要通过这条链路链路不通做什么都白搭。5. 调试串口、特殊芯片平台与游戏项目调试5.1 瑞芯微平台换调试串口改动点不止一个在瑞芯微平台上想换一个调试串口改动的地方比很多人以为的要多。通常需要同时在bootloader和设备树里动手因为早期启动阶段的日志走的是U-Boot内核起来后的输出走的是设备树指定的console。第一处是内核设备树里的chosen节点默认会有类似chosen { stdout-path uart2; };要把调试输出换到其他串口把uart2改成目标节点比如uart3。第二处是U-Boot的bootargs默认会有consolettyS2,1500000这里要和设备树保持一致否则内核起来时console会找不到。第三处是引脚复用也就是IOMUX目标UART引脚的复用模式要配置成UART功能否则电平信号根本出不来。我在改过一次之后才发现光改设备树里的stdout-path是不够的因为U-Boot阶段如果没把UART_CLK配置好串口乱码一片调试日志反而看不清。建议改完后先用示波器看目标引脚有没有波形再用串口助手确认波特率最后再看内核日志。这三步下来基本上不会有意外。5.2 紫光展锐平台的Debug模式与音频调试入口展锐平台我接触不算深但调试模式的基本链路跟大多数手机SoC是一致的AP侧会预留一个调试串口或基于ADB的调试通道工厂和软件版本里通常有对应开关。要打开Debug模式一般得在工程配置或者编译选项里打开对应开关让内核把调试口释放出来然后通过ADB连接、读取串口日志和audio模块的调试节点。音频调试方面展锐的Audio Tuning工具一般会通过USB ADB或者专用调试通道读取音频参数。基础思路是先进入工厂模式或者工程模式打开AUDIO的调试许可再抓取dumpsys audio相关输出或者声学参数节点。如果只是调音量曲线这类问题很多时候不需要改代码直接看audio配置文件里的音量映射表就行。这里给个通用建议入手陌生平台时不要指望能找到一条命令打开所有调试口。先去芯片手册或者SDK文档里找“debug mode enable”和“serial log”相关章节确认调试串口对应的GPIO和驱动节点再沿串口、驱动、上层工具这条线逐步验证。5.3 UE动画蓝图Debug的几个入口游戏引擎里的调试跟普通业务代码不太一样。UE的动画蓝图是一个可视化图表里面的节点状态、Transition规则、Blend权重都在运行期动态变化用传统的打断点方式反而不直观。我一般用下面几个入口。第一个是控制台命令showdebug animation在PIE运行时选中角色屏幕上会显示当前播放的动画、动画速率、是否被打断等关键状态连AnimMontage的Section也能看到。第二个是Animation Insights在开发者工具菜单里启停它能记录每一帧的动画计算耗时和Blend来源适合查性能型问题。第三个是AnimGraph里的Graph Debugging窗口可以直接在图表上看到当前哪条连线生效、权重是多少。还有一个小技巧在AnimNotify节点上接一个PrintString或者在AnimInstance的Blueprint里把某个Float变量拖到Watch窗口。做动画蓝图调试时很多问题本质就是“这个状态到底是哪个节点切过来的”把这些关键变量打印出来比猜快得多。6. 常见问题速查与我的调试小习惯6.1 三个印象深刻的bug实录第一个是前阵子在Python脚本里用IDLE调试断点设了但死活不停。后来发现我把pdb和IDLE的Debugger同时开了两者都在抢调试事件关掉其中一个就好了。第二个是STM32上UART数据错乱单步进中断服务函数时板子重启最后锁定是WWDG没暂停按DBGMCU配置解决。第三个是Java接口在本地跑得好好的远程一调就报ClassNotFound原因是服务端源码版本跟本地不一样。每个问题都不算深奥但在当时都消耗了我不少时间。回头你会发现多数坑都踩在“工具默认行为和你的预期不同”上而不是真正的算法难。所以我一直认为调试不是比谁打断点快而是比谁更了解工具在背后替我们做了什么。6.2 调试问题速查表顺手整理一张速查表基本覆盖这几个热词里对应的典型问题场景现象可能原因优先排查或解决方式单片机进入断点后反复复位IWDG/WWDG未在调试时暂停将DBGMCU-CR对应STOP位置1Release版确认恢复IDEA远程调试连接不上JDWP参数、端口、防火墙、源码不同检查监听端口和防火墙换高位端口确认服务端已加agent参数VSCode无法启动Keil工程调试缺少cortex-debug或没有带调试信息的ELF/AXF安装cortex-debug配置launch.json并指定带-g编译的ELFCCS停在initializing icepick_c_0目标未供电、JTAG链路异常、时钟过快检查供电复位降低JTAG频率核对Device配置IDLE断点不触发未开启Debugger菜单或与pdb冲突确认Debug-Debugger已打开或一次只用一种调试器程序在O2优化下断点看不到变量优化导致变量被折叠用Og或O0重新编译调试JNI崩溃fatal error in native methodNative库不匹配或JNI使用错误查看hs_err_pid日志重编native库调试日志提示check vendor daemons status软件License守护进程未启动检查License服务状态和对应日志这张表不完全覆盖所有情况但排查顺序大体一致先确认前提条件再动工具最后才怀疑代码。6.3 我一直保留的几个工作习惯最后整理几个我长期用着很顺手的习惯算是这篇记录的小结第一接到bug先写一句话描述在什么条件下、做了什么操作、看到了什么结果。这句话写完整了一半问题的排查方向就明确了。第二日志只留关键节点把细节日志收进编译开关。第三断点尽量加条件和计数逼自己想清楚触发条件。第四调试完一定要做回归因为测试时关掉的看门狗、优化等级、调试宏都要回到发布状态。我个人特别受益的是“复位源检查”这个习惯嵌入式程序启动后先读Reset Status寄存器记录复位原因串口打印出来这样很多偶发重启问题的证据链就有了。相当于在程序里装了个黑匣子等现场再出问题时能对着记录说话而不是全靠玄学。调试这个事慢慢就会从“碰运气”变成“问证据”这也是我这段时间最直接的感受。