JavaScript 断点调试实战:从 Chrome 到 VS Code 的全流程指南

作者:青柠

时间:2026-10-25

浏览:492

本文详解 JavaScript 断点调试的核心技巧,涵盖 Chrome DevTools 基础操作、VS Code 配置 SPA 应用与 Node.js 环境的方法,以及条件断点的高级用法。通过对比 console.log 的局限,展示如何利用断点将调试效率从 O(n) 提升至 O(1),并提供 launch.json 配置示例与 TypeScript 调试注意事项,帮助开发者高效定位复杂 Bug。

文章目录

为什么要使用 debugger

本文将深入解析如何利用断点高效调试 JavaScript 代码。在展开具体方法前,有必要先明确一个核心问题:为何必须使用断点进行调试?前端开发中,console.log 因其简单直接而成为最常用的调试手段,足以解决部分基础问题。然而,面对极其复杂的场景时,console.log 往往显得力不从心。例如:

  • 逻辑复杂的算法实现。 如果你有过 LeetCode 刷题经验,便会深有体会:当某个测试用例报错时,仅凭肉眼观察很难迅速定位到具体出错的方法或逻辑分支。
  • 复现步骤繁琐的 Bug。 耗费十分钟才勉强复现问题,却只能跟踪到某一行代码,若需继续排查还得再次添加 log 并重新查看。这种“查看 log -> 添加 log -> 再查看”的循环往复若频繁发生,将极大消耗时间,导致开发效率低下。
  • 运行流程冗长的代码段。
  • 缺乏注释且命名随意的代码。
  • 服务端代码。 拥有 Node.js 服务端开发经验的开发者,想必都经历过在 Postman 与 IDE 之间反复切换的痛苦。若仅依赖 log,面对庞大的复杂对象,控制台难以展示全貌。若接口还涉及数据库增删或第三方依赖调用,复原上一次请求造成的副作用将是一项艰巨任务。

在上述场景中,断点调试展现出极高价值,它能将调试的时间复杂度从 O(n) 降低至 O(1),让开发工作更加高效愉快。

本文内容大纲如下:

  • Chrome debugger 基本用法
  • VS Code 调试 SPA 应用
  • Chrome 调试 Nodejs
  • VS Code 调试 Nodejs

Chrome debugger 基本用法

最基础的断点调试方式,是在代码中插入一句 debugger,随后在浏览器中刷新页面,此时浏览器执行至该语句时会自动暂停。

为便于理解,引入一个简单示例:在文件夹中创建 index.html 和 index.js,并在 index.html 中引入 index.js。index.js 内容如下:


// 国际惯例,hello world。
const greet = () => {
  const greeting = "hello debugger";
  // 浏览器执行到这里将会暂停
  debugger
  console.log(greeting);
};

greet();

console.log("js evaluation done");

执行命令:


npm i -g serve
serve .

随后访问 http://localhost:5000 并打开开发者工具。

此时我们的 hello world 断点已生效,效果如下:

为什么要使用 debugger

图中界面分为四个区域:蓝色区域用于文件选择,Page 栏显示当前页面的 JS 文件,Filesystem 显示系统文件,通常我们使用 Page 栏。

粉色区域显示代码行号与内容。点击行号可添加新断点,再次点击则取消。

黄色区域用于控制代码执行,掌握前四个按钮即可应对绝大多数场景。按钮 1 为继续执行(resume),遇到下一个断点时会再次暂停;按钮 2 允许浏览器执行当前行(图中为第 3 行),并在下一行中断;按钮 3 用于进入当前函数,查看其具体内容。假设当前停在第 7 行 greet(),点击按钮 3 将进入 greet 方法(即第 2 行)。若无需继续查看 greet 方法,可点击按钮 4 跳出该方法,回到第 8 行。

绿色区域用于查看变量内容及当前调用栈。

debugger 是最简单直接的打断点方式,但需修改代码。需注意,上线前必须删除这些语句,也可通过配置 webpack 自动去除。尽管如此,这种方式仍显不便,因此下文将介绍如何通过 VS Code 简化打断点流程。

VS Code 调试 SPA 应用

首先,我们使用 Vite 创建一个 Vue 应用用于演示(React 步骤类似)。


# 创建 vut-ts 应用
npm init vite
cd hello-vite
npm install
# 调用 VS Code cli 打开项目,或者手动在 VS Code 打开。
code .
npm run dev

随后在 VS Code 中新建 .vscode/launch.json 文件,填入以下内容:


{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "pwa-chrome",
      "request": "launch",
      "name": "Launch Vue project",
      // 这里填入项目的访问地址
      "url": "http://localhost:3000",
      "webRoot": "${workspaceFolder}"
    },
  ]
}

接着使用 cmd+q 退出正在运行的 Chrome(此步至关重要,不可跳过),按 f5 启动 VS Code 调试功能。VS Code 将自动启动一个 Chrome 窗口,并访问配置中的 url。此时断点已生效,可逐步控制代码运行以定位 Bug。

为什么要使用 debugger

这里有一个实用技巧:在 BREAKPOINTS 面板中勾选 Uncaught Exceptions,这样当代码报错时会自动中断执行。遇到报错时,此方法可省去定位问题代码的时间。

为什么要使用 debugger

此外,当 VS Code 断点生效时,Chrome Devtools 也会同步显示该断点。

为什么要使用 debugger

在 VS Code 中,调试分为 launch 和 attach 两种模式。由于实际执行代码的是 Chrome 中的 JS 引擎,因此控制代码中断的权限在 Chrome 手中。VS Code 断点之所以能控制中断,是因为 VS Code 通过 devtools-protocol 向 Chrome 发送指令,告知其在哪一行代码暂停。这一发送指令的过程称为 attach。而 launch 过程包含 attach,即先启动浏览器,再附加断点信息。因此,attach 模式是 launch 模式的子集。

听起来 launch 模式更为便捷,省去了手动启动浏览器的步骤。但若同时开发多个前端工程,每个工程启动一个调试进程便会打开多个浏览器,导致在多个浏览器间切换极为麻烦。我们可以使用 attach 模式解决此问题。

首先通过命令行启动 Chrome。使用命令行是为了给 Chrome 传递参数。


# 运行这条命令前需要cmd+q退出已运行的Chrome
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222
# 如果看到这个输出,说明传参成功。
DevTools listening on ws://127.0.0.1:9222/devtools/browser/856a3533-ca5c-474f-a0cf-88b7ae94c75b

VS Code 与 Chrome 通过 websocket 通信,--remote-debugging-port 指定了 websocket 使用的端口。随后将 launch.json 文件修改如下:


{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "pwa-chrome",
      "request": "attach",
      "name": "Vue Application",
      // 项目访问的 url
      "url": "http://localhost:3000",
      // websocket 端口,需要与 --remote-debugging-port 参数保持一致。
      "port": 9222,
      "webRoot": "${workspaceFolder}"
    },
  ]
}

注意,启动 VS Code 调试前,需在 Chrome 中打开 http://localhost:3000 页面。随后在 VS Code 中打上断点并刷新浏览器,代码即可成功停在断点处。第二个、第 n 个工程均可采用相同配置,区别仅在于 url 字段需根据项目配置修改。

Chrome 调试 Nodejs

上文介绍了页面调试方法,接下来讨论如何调试 Node.js 应用。首先来看一个简单示例,创建一个 hello world:


// debug.js 文件
const greeting = 'hello nodejs debugger'
debugger
console.log(greeting)

然后运行该文件。


node --inspect-brk debug.js
Debugger listening on ws://127.0.0.1:9229/b9a6d6bf-baaa-4ad5-8cc6-01eb69e99f0a
For help, see: https://nodejs.org/en/docs/inspector

--inspect-brk 表示运行该 js 文件的同时,在文件第一行打上断点。随后打开 Chrome,进入 Devtools。点击红框处按钮,即可打开 Node.js 专用调试窗口,代码将在第一行中断。

为什么要使用 debugger

Node.js 调试窗口:

为什么要使用 debugger

此方式的实质是,Chrome Devtool 根据 v8 引擎的调试协议向 Node.js 进程发送指令,控制代码运行。可以发现,在网页调试中,Chrome 是接收指令的一方;而在 Node.js 调试中,Chrome 转为发送指令的一方,可谓从“乙方”华丽转身为“甲方”。

Node 默认的 websocket 端口是 9229。若有需要(如端口被占用),可通过以下方式更改端口。


node --inspect=9228 debug.js
Debugger listening on ws://127.0.0.1:9228/30f21d45-9806-47b8-8a0b-5fb97cf8bb87
For help, see: https://nodejs.org/en/docs/inspector

打开 Devtool 时,Chrome 默认检查 9229 端口。但更改端口号后,需手动指定 Chrome 检查的地址。点击图中 Configure 按钮,输入 127.0.0.1:9228,然后点击 Done。此时 Remote Target 中将显示刚才启动的 Node 进程,点击 inspect 即可进入调试。

使用 VS Code 调试 Nodejs

至此,我们已实现调试 Node 的目的,但过程仍显繁琐,不够自动化。我们可以使用 VS Code 来一键启动调试。

用 VS Code 打开刚才的工程,然后在 launch.json 中输入以下内容:


{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "pwa-node",
      "request": "launch",
      "name": "Launch Program",
      "skipFiles": [
        "<node_internals>/**"
      ],
      // ${file} 的意思是,当我们启动调试的时候,调试的程序就是当前 focus 的文件。
      "program": "${file}"
    }
  ]
}

随后切换到 index.js 文件,按 f5 启动调试程序。当运行至第二行 debugger 语句时,将自动暂停执行。也可点击代码行号左侧来打断点。

若需调试 TypeScript,只需将 index.js 重命名为 index.ts,并修改 launch.json。


{
  "type": "pwa-node",
  "request": "launch",
  "name": "Launch Program",
  "skipFiles": [
    "<node_internals>/**"
  ],
  "program": "${file}",
  // 在调试之前,需要将 TypeScript 编译成 JS.
  "preLaunchTask": "tsc: build - tsconfig.json",
  
  // 这里是在告诉 VS Code,编译后的代码文件输出到了哪个位置。
  // 需要在 tsconfig.json 中,将 outDir 指定为 dist。
  "outFiles": [
    "${workspaceFolder}/dist/**/*.js"
  ]
}

对于 TS 调试有两个注意点:

  1. launch.json 中的 outFile 路径,需与 tsconfig.json 中的 outDir 保持一致。
  2. tsconfig.json 中将 sourceMap 指定为 true。

Conditional Breakpoint 条件断点

某些情况下,我们不希望每个断点都生效,而是仅在执行到断点所在行且满足特定条件时才中断代码。这就是条件断点。


for (let i = 0; i < 10; i++) {
  console.log("i", i);
}

例如上述代码,假设我们在第二行 console.log 打了断点,则该断点总计会中断十次。这往往非我们所愿,可能只需其中某一次循环而非全部。此时可右键点击并选择 Add Conditional Breakpoint。

为什么要使用 debugger

此时会出现一个输入框,在其中输入 i === 5。

为什么要使用 debugger

随后启动调试,将跳过 i 为 0 - 4 的情况,直接在 i 为 5 时中断代码执行。恢复代码执行后,将略过 i 为 6 - 9 的情况。

Conditional Breakpoint 在调试带有大量循环和 if else 判断时极为有用。特别是当某处逻辑整体符合预期,仅个别特殊情况输出错误时,使用条件断点可跳过正常情况,仅在个别特殊情况下中断执行,供我们查看各变量计算是否正常。

总结

调试是日常工作中至关重要的能力,因为除开发新功能外,日常仍有大量时间用于调整旧代码、处理特定条件下的逻辑错误。熟练掌握调试可显著提升开发幸福感,一个复杂 Bug 卡壳数小时极易让人心态崩溃。但断点调试并非适用于所有情况的银弹,简单逻辑仍可使用 console.log。本文介绍了使用 Chrome Devtools 和 VS Code 进行断点调试的方法,整体更推荐使用 VS Code。launch.json 只需配置一次,后续均可通过 f5 一键启动调试。此外,文中提及的各种 launch.json 配置,均可使用 VS Code 自带工具一键生成。只需打开 launch.json,编辑器右下角将出现 Add Configuration 按钮,点击即可选择所需添加的调试配置。

到此这篇关于 JavaScript 必备的断点调试技巧的文章就介绍到这了,更多相关 JavaScript 断点调试技巧内容请搜索本站以前的文章或继续浏览下面的相关文章,希望大家以后多多支持本站!

实用工具推荐

电子包浆

绿化、压缩、噪点和虚拟水印,自由调节做旧程度。

使用 ›
图片压缩

选择画质和输出格式,预览压缩前后的大小。

使用 ›
相关文章