为什么你还在用console.log调试？

每次看到代码里满满的控制台输出，我就想起曾经的自己。一个Bug排查一下午，console.log打了十几行，删的时候生怕漏掉哪个。同事路过瞄一眼，问一句：「怎么不用断点？」我愣了一下：「断点怎么用？」

相信我，你不是一个人。太多开发者把console.log当成调试标配，却忽略了VSCode自带的调试功能有多强大。今天把这几个最实用的技巧分享出来，帮你把调试效率提上去。

1. 断点不只是暂停

很多人以为断点就是让代码暂停在那，然后一步一步走。其实断点的玩法远不止于此。

条件断点是我最常用的功能之一。右键点击行号左边的空白处，选择「添加条件断点」，输入一个表达式。只有当表达式为true时，代码才会停在这里。比如在循环里排查问题，你想在某个特定条件下暂停，完全不需要手动狂按「继续」：

for (let i = 0; i < 100; i++) {
  // 条件断点: i === 50
  processItem(items[i]);
}

日志断点更香。右键断点，选择「编辑断点」，然后切换到「日志消息」。这样代码经过这里时不会暂停，而是直接在控制台输出一你想打印的内容。调试完了直接删掉断点就行，不用满地找console.log删半天。

2. 调用栈不只是用来「追根溯源」

一旦代码在断点停住，右上角的「调用栈」面板往往被忽略。其实这里藏着很多有用的信息。

当你发现某个变量值不对，但又不知道是谁传错了的时候，调用栈就是最好的排查路径。点开调用栈的每一层，看看每一步的参数是什么，一层层往下追，很多问题瞬间就清楚了。

还有一个容易被忽视的功能：重启帧。在调用栈的某一帧上右键，选择「重新启动帧」，可以让代码从这一帧重新执行。这在尝试不同参数时特别有用，不用刷新整个页面或重启服务。

3. 调试面板不只是看变量

很多人知道在「变量」面板里查看当前作用域的变量值，但往往不知道这几个技巧：

• 右键变量选择「添加到监视」：把这个变量加到单独的监视面板，退出调试后再次进来还在。对于需要持续关注的变量，这个功能比来回翻作用域方便太多。
• 在控制台直接执行代码：断点暂停时，下方的调试控制台其实是一个完整的REPL。你可以直接输入表达式查看结果，甚至可以给变量赋新值来测试不同的场景。比如你发现某个参数不对，直接改掉再继续跑，看看结果是否修正。

4. 不同类型项目的调试入口

前端项目和Node.js后端项目的调试入口不太一样，但VSCode都支持得很好。

前端项目：在Chrome或Edge浏览器里调试是最流畅的。VSCode装好Debugger for Chrome插件，点击「调试」标签，选择「Chrome」然后按F5，浏览器和VSCode的断点就自动打通了。后端API和前端页面一起调的时候，这种方式最顺手。

Node.js后端：直接点击「Node.js」配置就行。如果你的项目用了pm2或者docker，直接在终端里启动调试模式也行：

node --inspect-brk index.js

VSCode会自动检测到调试端口，跳转到对应的调试配置。

5. 远程调试不玄乎

很多人不知道VSCode支持直接调试远程服务器上的代码。其实配置起来很简单：

1. 在远程服务器上用 --inspect 参数启动Node.js
2. 在VSCode里配置「远程调试」，填入服务器的IP地址和调试端口
3. 本地的断点直接打在代码上，远程服务器执行时就会停在你设置的位置

这条在排查生产环境问题或者调试测试环境时特别有用。不必再到处加打印，重现问题后打断点一调便知。

回到开头的问题：为什么你还在用console.log调试？

不是console.log不能用——它确实方便，临时看个值很顺手。但当问题稍微复杂一点，比如循环里的异常条件、多个函数嵌套的参数传递，console.log的效率就远远跟不上了。

花10分钟学会这几个断点技巧，下次遇到Bug，你可能会发现自己只用2分钟就定位到了。试试看？