前端debugger调试

最新推荐文章于 2024-04-16 15:10:42 发布

远远吖

最新推荐文章于 2024-04-16 15:10:42 发布

阅读量524

点赞数 1

文章标签：前端

本文链接：https://blog.csdn.net/weixin_68542759/article/details/133950402

版权

为什么要使用 debugger

我们首先需要认可使用断点的是必要的，否则下文介绍的所有断点调试方法都会是废话。console.log 是前端开发最常用的调试手段，它简单直接解决一部分问题。但当遇到十分复杂的问题，console.log 就会不太满足需求。比如：

一个逻辑复杂的算法
如果你刷过 leetcode 一定深有体会，算法某个测试用例报错了，有时很难光靠目测找出有问题的那个方法。
一个复现步骤十分繁琐的bug。
花了10分钟好不容易复现了，但是只跟踪到某行代码，需要第二次添加 log 才能继续寻找问题。查看log -> 添加log -> 查看log... 这个过程重复几遍，今天剩下的砖就搬不完了。
一段运行流程冗长的代码
一段没有注释、起名随意的代码
server 端代码
有 nodejs 服务端开发经验的同学相信有过在 postman 和 ide 之间反复横跳的经历，如果光靠 log，对于一个巨大的复杂对象，控制台是不好查看全貌的。如果一个接口还涉及到数据库增删、第三方依赖，那么复原上一次请求造成的后果也是一件痛苦的事情。

Chrome debugger 基本用法

最简单的断点调试，就是在代码中加一句 debugger，然后到浏览器中刷新页面，这时候浏览器就会在 debugger 语句那停止执行。

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 断点就打上了，就像这样：

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

粉色是代码的行号和内容。代码的行号处可以通过点击来添加新的断点，再次点击后取消。

黄色区域用于控制代码的执行，只需要掌握前四个按钮的含义，就可以应付绝大多数场景。按钮1是让代码继续执行(resume)，如果遇到下一个断点就会再次中断执行。按钮2可以让浏览器执行当前行(图中是第3行)，然后在下一行中断代码，按钮3是进入当前函数，查看函数具体内容。假设我们当前停在第7行 greet() ，点击按钮3就会进入 greet 方法中(也就是第2行)。如果不想再看 greet 方法了，就点击按钮4，跳出这个方法，回到第8行。

绿色区域可以查看变量的内容和当前的调用栈。

debugger 是最简单粗暴的打断点方式，但是需要修改我们的代码。需要注意的是，上线前必须删除这些语句。也可以通过配置 webpack 来自动去除。不过终究还是有些不方便，所以我们来看下如何通过 vscode 来简化打断点的方式。

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 来源。

这里有一个实用的小技巧，就是在 BREAKPOINTS 中，把 Uncaught Exceptions 勾上，这样在代码报错的地方，就会自动中断执行。当我们遇到一个报错时，采用这个方法可以省去定位问题代码的时间。

另外我们可以发现，在 VS Code 断点生效时，Chrome Devtools 也会同步这个展示这个断点。

在 VS Code 中，调试有两种模式，分别是 launch 和 attach。由于真正执行代码的是 Chrome 中的 JS 引擎，所以是否中断代码的控制权是在 Chrome 手里的。那为什么 VS Code 的断点可以控制代码的中断呢？是因为 VS Code 通过 devtools-protocol 向 Chrome 发起指令，告诉 Chrome 需要在哪一行代码暂停执行。这个发送指令的过程，被称作 attach。而 launch 的过程包含 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}"
},
]
}