2.4 调试辅助：给工位配万用表

2.4 调试辅助：给工位配万用表

本节摘要：调试装备的核心是让错误就地可见、让暂停点精准可控。本节把诊断信息从问题面板搬到行内，配齐断点的普通档、条件档、日志档，管理调试会话的启动配置，并给出"打印调试与断点调试"的取舍。电路出问题时，万用表比盯着看有用得多。

凌晨一点，一段循环逻辑跑出了诡异结果，你在代码里插打印语句、跑一遍、删掉、换个位置再插——如此往复，天亮前终于定位。这段经历几乎每位开发者都有。事后复盘，浪费时间的不只是反复插拔，而是每轮"改代码、重启、肉眼看日志"的回路太长。工匠查电路不靠肉眼，靠万用表：表笔搭上去，数值就地读出来。编辑器的调试装备就是这块表，上一节装好了导航挂板，这一节把检修工具配齐。

适用场景：什么时候该正式配表

两个信号。其一，问题面板里的错误要靠肉眼扫文件名再定位到行，来回切换太慢——错误应该出现在出错的哪一行旁边。其二，调试依赖"打印大法"，且每轮插入删除打印语句超过一分钟——回路太长，该用断点让程序停在出事现场。反过来，纯语法错误、格式化能救的问题，都不需要这块表，别把调试器当摆设。

行内诊断：把表笔搭在行上

第一件装备是行内错误显示扩展：语言服务产出的诊断信息不再只沉在底部问题面板，而是直接渲染在出错代码行的行尾与行间。效果立竿见影——拼写错的变量名、类型不匹配的传参、未使用的导入，一眼扫过代码就在原地暴露。对它的配置集中在"显示多少"与"是否太吵"：

{
  "errorLens.enabled": true,
  "errorLens.excludeBySource": ["cSpell"],
  "errorLens.messageMaxChars": 120,
  "errorLens.delay": 300
}
​

排掉拼写检查器的诊断（那类噪声多）、截断超长消息、加一点延迟防抖——这几项都是让它"只报要紧事"的降噪配置。行内显示是纯渲染层装备，轻，收益却极大，我把它列为调试装备的第一优先。

断点的档位

第二件装备不是插件，而是把内置断点的档位用全。普通断点人人会用；真正拉开效率的是另外几档：

• 条件断点：右键断点加条件表达式，只有条件成立才停——在循环里找"特定那一次"的异常时，不用手动continue几百轮；
• 命中计数断点：第多少次经过时才停，与条件档配合可以精确定位偶发问题；
• 日志断点：经过时不暂停、只输出一条日志——它就是"不用改代码的打印语句"，插上就走，拔掉即无痕，直接替代凌晨那轮反复插拔。

断点之外，调试视图的"变量区、监视区、调用栈"三块表盘要养成看的习惯：监视区手动添加关心的表达式，程序停下时只读这几个数；调用栈往上一层点一下，就能看到"是谁调的这里"——多数逻辑错误的答案在调用方。

调试会话的启动配置

第三件装备是会话管理。调试器怎么启动、传什么参数、停在哪，都写在启动配置文件里（位于工作区的调试配置目录）。给它建立"每个场景一份"的档位：

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "当前文件调试",
      "type": "node",
      "request": "launch",
      "program": "${file}",
      "console": "integratedTerminal"
    },
    {
      "name": "附加到运行中的进程",
      "type": "node",
      "request": "attach",
      "processId": "${command:PickProcess}"
    }
  ]
}
​

launch 档从零启动被调试程序，attach 档把表笔搭到已经在跑的进程上——服务已经起了、问题出现在运行态，就用附加档，不必重启。这份文件随仓库走，团队的调试习惯就固化成了图纸。各语言的调试适配详见第 4 章的语种整备节。

台面实测：一个偶发问题的诊断过程

拿一个真实形态的案例过一遍全流程。某接口每处理到特定条件的订单就返回错误，频率不定。旧打法：加打印、压测、肉眼过滤日志，一轮约十分钟，反复七八轮。新打法：在处理函数入口下条件断点，条件写订单的判断式；触发压测，程序恰好停在出事的那一次请求上；看变量区确认入参形态，看调用栈发现上游传了未初始化的字段——从启动到定位，一轮压测之内完成。差距不在"找得更快"，而在程序停在案发现场，证据还是热的。

坑点提醒

坑一，行内显示太吵。 装上后满屏红字反而干扰，用排除配置把低价值来源（拼写、样式类）滤掉，只留正确性诊断。坑二，断点让服务卡死。 在高流量入口下普通断点，程序一停队列就堆积；这类位置改用日志断点，或只在测试环境用暂停档。坑三，启动配置失同步。 手工改了运行参数没同步进配置文件，下次同事按图纸启动又踩同一个坑——调试参数变动后随手更新配置，把它当代码维护。

替代方案

最重的替代路线是专业调试器图形界面，功能全但上下文切换成本高，多用于疑难杂症。最轻的路线仍是打印调试——注意，它并非一无是处：分布式链路、异步竞态这类"停了就变样"的问题，日志反而比断点可靠。成熟的工位不站队，断点管现场审讯，日志管事后回放，两样都有各自的位置。

常见疑问快答

问：行内错误显示开着，但有些错误还是只出现在问题面板？答：检查该诊断的来源——部分装备产生的诊断默认不进行内渲染，可在行内显示装备的设置里调整来源过滤；另外消息超长的诊断会被截断，完整内容仍以问题面板为准。行内显示是“快览层”，面板是“全量层”，两层都要留着。

问：日志断点和打印语句，最终该留谁？答：调试期的探索用日志断点——随插随拔不留痕；稳定后有保留价值的观测点，沉淀为正式的日志语句进代码（带级别与上下文）。一个进调试器、一个进日志系统，归宿不同，不是二选一。

问：调试结束要做什么收尾？答：两件事——拔断点（或把临时断点批量清掉），关掉为这次排查临时开的调试配置档。带着一身高亮断点继续写代码，下次调试会掉进旧战场，这类“调试残留”是隐形的时间窃贼。

收束与下一站

万用表配齐：行内诊断让错误就地曝光，断点档位让暂停精准可控，会话配置让团队的调试习惯可复用。基础五件套还剩最后一件——版本控制登记簿，下一节把"后悔药"正式摆上工位。