前端调试的最佳实践

一、背景

作为前端工程师，无论是开发还是线上环境，浏览器或是 node，移动端或者 PC 端，经常会遇到一些 bug，那么如何快速定位和解决问题呢，笔者准备了一份前端调试指南供大家参考。

「文章大纲」：

调试本身可以分为两个过程，「定位问题」 和 「解决问题」。而更重要的显然是如何快速的定位问题。本文将集中讨论如何 「快速发现」 并 「调试问题」，至于如何解决问题，那就是开发本身的事情，无法一概而论了。

二、调试工具方法

2.1 Chrome DevTools 的使用

Chrome 的 DevTools 是最常用的调试工具，下面主要介绍下 「Elements」、「Console」 和 「Source」 三个面板的使用。

2.1.1 Elements

Elements 面板会显示目前网页中的 DOM、CSS 状态，且可以修改页面上的 DOM 和 CSS，即时看到结果，省去了在编辑器修改、储存、浏览器查看结果的流程。

Elements 主要可以分为 DOM 结构以及元素（Element）内容两个子面板，下面主要介绍一下 Elements DOM

$n

开启 Elements 面板时，标记的元素后方总会有个 == $0

image-20220116212438893

选中一个元素后再到 Console 面板输入$0，会发现刚刚选中的元素出现在 Console 中,如果再多点几个元素，还可以用$1、$2、$3、$4（到此为止）来拿到前几次选到的元素。

另外在 Console 中对元素按下右键，选择 Reveal in Elements Panel 可以跳到该元素在 Elements 面板中的位置，对 Elements 面板的元素按下右键则有 Scroll to view 可以把视野滚到能看见元素的地方。

想要在 Console 面板中用 JavaScript 操作元素时，$0就非常方便，另外也可以搭配 console.dir($0) 来观察元素的各个属性，如果在 Console 直接输入 $0 或是 console.log($0) 只会显示元素自身。

image-20220116212412476

inspect

有时候一些 dom 节点会嵌套很深，导致我们很难利用 Element 面板 html 代码来找到对应的节点。inspect(dom元素)可以让我们快速跳转到对应的 dom 节点的 html 代码上。 eg：在 console 输入inspect($('#app'))，回车后便可以跳转到#app 节点的 html,进行审查元素

2.1.2 Console

Console 面板作为 shell 提示窗口用来和页面文档以及 DevTools 进行交互

console 对象

前端说起调试，最常用的肯定就是console.log方法，但是 console 是一个对象，上面还有很方便的方法。

console.table() 可用于打印 obj/arr 成表格

image-20220104154752095

console.trace() 可用于 debugger 堆栈调试，方便查看代码的执行逻辑，也可以帮助我们看一些库的源码

image-20220104155335803

console.count会印出这个标签被执行了几次，预设值是default，可以用在快速的计数。

console.countReset与 count 配套，用来重置，可用在计算单次行为的触发的计数。

console.group() / console.groupEnd();

为了在一大堆混乱的讯息中一眼看到自己的 log, 通常会这样做

console.log("----start-----");
console.log(object);
console.log("---end---");

虽然 --- 是很显眼没错，但其实有更好的做法，用console.group 可以自订 Message group 的标签也可以多层嵌套，并用 console.groupEnd 来关闭 Group

console.log("iteration");
for (var firstLevel = 0; firstLevel < 2; firstLevel++) {
  console.group("First level: ", firstLevel);
  for (var secondLevel = 0; secondLevel < 2; secondLevel++) {
    console.group("Second level: ", secondLevel);
    for (var thirdLevel = 0; thirdLevel < 2; thirdLevel++) {
      console.log("This is third level number: ", thirdLevel);
    }
    console.groupEnd();
  }
  console.groupEnd();
}

$$(select)方法

$(select) 拿到的是 NodeList(伪数组)，而 $$(select) 拿到的则是一个纯正的数组，方便我们在控制台上调试 API,只有在 devtools 下打印才能使用

image-20220104155823831

2.1.3 Source

Sources面板可以查看浏览器页面中的源文件（html/js/img/css等），点击面板下方的{}大括号可以将代码转成可读格式，同时可给js文件添加上断点。Sources下的Snippets可以添加文件片段，可在浏览器中运行

Breakpoints

「debugger 语句」

在代码中加上debugger语句，是仅次于console.log的常用调试方式，在需要的地方进行添加断点

chrome devtool breakpoint 下面列举一些平常使用较多的断点方式

• 普通断点：在想断住的那一行左侧单击一下就可以添加一个断点，运行到该处就会断住。

  image-20220104161116371

• 条件断点：右键单击代码所在的行左侧，会出现一个下拉框，可以添加一个条件断点。输入条件表达式，当运行到这一行代码并且表达式的值为真时就会断住。

image-20220104161315275

• DOM 断点：在 Chrome Devtools 的 Elements 面板的对应元素上右键，选择 break on，可以添加一个 dom 断点，也就是当子树有变动、属性有变动、节点移除这三种情况的时候会断住。可以用来调试导致 dom 变化的代码。

image-20220104161458483

• Event Listeners 打断点：在 Chrome Devtools 的 Elements 面板上找到你想排查的 dom 节点，右侧面板 Event Listeners 中会有当前阶节点，可以当前节点打断点调试。

  image-20220104161916972

• 异常断点：在 Debugger 面板勾选 Uncaught Exceptions 和 Caught Exceptions 可以添加异常断点，在抛出异常未被捕获或者被捕获时断住。用来调试一些发生异常的代码时很有用。

• Event Listener 断点：在 Chrome Devtools 的 Sources 面板还可以添加 Event Listener 的断点，指定当发生什么事件时断住，可以用来调试事件相关代码。比如拖拽事件、媒体事件断点

• Function 在 Console 面板中可以用 debug 相当于在该 function 的第一行插入debugger：

function a() {
  console.log(1);
}
// 在Console中输入
debug(a);
a();

// 相当于
function a() {
  debugger;
  console.log(1);
}
// 使用 undebug 解除

BlackBox

“BlackBox Script”可以在调试中忽略某些脚本(此处的 BlackBox 为动词)，在 Call Stack 堆栈中会将该脚本隐藏，单步调试时也不会步入脚本中的任何函数。如果确认第三方库没有 bug，就可以 BlackBox 整个第三方库的 js 脚本，在调试中跳过这些代码的执行。

三种添加 BlackBox 的方法：

1. 在源代码窗格右键，选择"BlackBox Script"
2. 在 Call Stack 中右键某一帧，选择"BlackBox Script"
3. 在设置中的 Blackboxing 面板添加「正则表达式」匹配「文件名」

Workspace

chrome 中「使用本地 sourceMap 调试」

第一步：打开 Filesystem add folder to workspace，把包含 sourceMap 的目录添加进去

image-20220104171549241

第二步：打开指定的混淆代码

image-20220104171821907

第三步：右键 -> 选择【Add source map】

第四步：拷贝 Filesystem 中的 sourceMap 地址。

在 chrome 中修改代码并调试

chrome devTools 提供了 local overrides 能力，首先，打开 sources 下的 overrides 面板；

然后，点击【select folder for overrides】选择修改后的文件存储地址；

image-20220104172628695

再然后，点击顶部的授权，确认同意；

最后，找到入口文件，然后右键选择 Save for overrides (一定要是原件，formatted 后的版本不行),

image-20220104173000023

然后找到保存的文件进行修改，重新刷新页面后，修改后的代码就可以被执行了。

2.2 nodejs 调试

Nodejs 使用 Chrome DevTools 调试 --inspect-brk

下面以调试 webpack 源码为例：

node --inspect --inspect-brk node_modules/webpack/bin/webpack.js --env.production --config webpack-common.js

执行 bin 中相应「启动文件」webpack.js 打开 chrome 的开发者工具页面，如果看到 node 的「绿色图标」，点击就可进入调试。

img

2.3 移动端调试 VConsole 与 eruda

whistle 配合 VConsole 或者 eruda，可以在任何环境下开启调试模式，在 whistle 中 规则中配置相应域名下进行调试，以 m.zhuanzhuan.com 域名为例

m.zhuanzhuan.com jsAppend://{eruda.js} jsAppend://{erudaInit.js}

下载 eruda.js，把 eruda.js 和 erudaInit.js 配置在 values 中

image-20220104164430460

image-20220104164328168

这样就会在移动端开启调试 eruda 模式了。

2.4 微信 WebView 调试

微信调试网页，正常来说你可以使用微信开发者工具[1] 进行调试。它本质上和 chrome://inspect 方法类似，只是它为线上的微信包提供了 debug 模式，并将操作简单化。具体的使用方法可以参考官方文档：https://x5.tencent.com/tbs/guide/debug/season1.html

2.5 Android Chrome 真机调试

如果你需要调试的 Android 手机版本 >= 4.4，则推荐使用 chrome://inspect 的方式进行调试，它能为 WebView 带来原生的开发者工具，可以方便的对代码进行断点调试。该方法需要满足以下三个条件才能使用：

1. Android 4.4+
2. 手机上开启允许 USB 连接设备进行调试
3. 客户端开启 WebView debug 模式

//开启 webview 的 debug 模式
webview.setWebContentsDebuggingEnabled(true);

当满足以上要求之后，访问 chrome://inspect，页面将显示您的设备上已启用调试的 WebView 列表。要开始调试，请点击您想要调试的 WebView 下方的 inspect。像使用远程浏览器标签一样使用开发者工具。

2.6 iOS Safari 真机调试

如果你手机上安装的是 DEBUG 版应用，那么推荐使用 Safari 来调试，它能为 WebView 带来原生的开发者工具，可以方便的对代码进行断点调试。该方法需要满足以下三个条件才能使用：

1. Mac: Safari -> 偏好设置 -> 高级 -> 在菜单栏中显示“开发”菜单勾选
2. iOS: 设置 -> Safari -> 高级 -> Web 检查器打开
3. 最重要的是 App 必须开启 DEBUG 模式

由于 iOS 有签名校验机制，真机正式包不允许 Safari Debug，所以安装在真机上的包必须是测试签名打的包。需要联系客户端将我们 iOS 设备的 ID 写入到可信任设备列表中，然后使用 iTunes 安装客户端提供的测试包即可。当满足以上要求后，就可以在 Safari -> 开发中看到自己的设备以及 WebView 中网页，点击后即可开启对应页面的 Inspector，可以用来进行断点调试。

2.7 weinre 调试

当系统版本或者未开启 debug 模式导致上面的方法不可用时，可以考虑使用 weinre[2]。weinre 通过在页面中插入一段脚本，将页面的所有行为发送到服务上。首先我们需要安装并启动服务：

npm install -g weinre
weinre --httpPort 8000

访问 http://localhost:8000 按照页面提示将 debug 脚本插入到页面中。访问页面后就会发现 winere 页面中出现了对应的请求记录，点击该记录即可跳到如下页面。可以看到这个就是一个网页版的开发者工具，可以方便的查看网络请求，控制台执行代码以及样式修改等。

三、调试方法汇总

四、调试一般步骤

当出现异常时，按照这个基本逻辑排查，一般可以快速定位问题。

4.1 检查控制台是否报错

可以快速确定页面不符合预期的原因

• 是何种错误
• 当前页面是否需要请求获取数据

4.2 是何种错误

• 安全错误：与后端协商解决
• SyntaxError/ReferenceError/TypeError ：编译阶段一般不会放过太低级的书写错误，可以认为这类错误都是写错了 ，一般很容易发现，找到错误堆栈进行解决
• 数据不符合预期引起的错误（TypeError 等）：访问不存在的属性得到了undefined/null/NaN等值之后，会引发后续的异常。要先从检查数据入手。

4.3 当前页面是否需要请求获取数据

网络请求是不稳定因素之一，可能会带来难以预料的复杂情况，出现问题的时候检查网络请求和数据的优先级很高。

4.4. 网络请求是否成功发送

检查开发者工具 Network/网络面板，查看需要获取数据的接口是否成功获取到数据。

取不到数据的原因有两类，一类是责任在前端，一类是后端。主要通过请求提交的内容是否合法，接口返回内容是否符合预期两个方面判断。

查看的关键点：

• 方法是否正确
• URL 是否正确
• 跨域
• 请求的 Content-Type 是符合要求
• 请求体格式是否符合要求（JSON/Form）
• 是否携带了身份信息

合法请求没有得到预期返回，就找后端解决，请求与预期不符就是代码写错了，到错误地方查看代码。

• 500 等不该出现的异常：500 大概可能是后端问题
• 404 URL 写错
• 权限问题:检查请求报文携带的身份信息

4.5 定位到代码应当执行的位置（大概即可）

如果是控制台有错误信息的，利用 sourcemap 可以快速定位到问题出在哪一行。如果没有报错信息，就需要凭借当前页面的状态自己判断出问题的区域，按照代码执行的顺序排查。这一步可以利用的手段比较多，情况也更复杂，需要具体分析。

查看代码运行状态：

• 按照预期执行顺序检查代码
• 检查渲染需要的数据是否与预期相同

4.6 按照预期执行顺序检查代码

通过断点、日志等手段判断程序有没有按照自己想要的顺序执行，简单来说就是排查。

4.7 检查渲染需要的数据是否与预期相同

检查运行过程中每一步的数据变化，是否与预期的相同。

4.8 异常代码一般分析方法

• 「代码注释法」 利用二分法思想逐行去注释代码，直到定位问题
• 「类库异常，兼容问题」 这种场景也会经常遇到，我们需要用可以调试页面异常的方式，如 Safari，Whistle，vConsole 查看异常日志，从而迅速定位类库位置，从而找寻替换或是兼容方案。
• 「try catch」 如果你的项目没有异常监控，那么在可疑的代码片段中去 Try Catch 吧。
• 「ES6 语法兼容」 一般我们都会通过 Babel 来编译 ES6 ，但是额外的第三方类库如果有不兼容的语法，低版本的移动设备就会异常。所以，先用上文讲述的调试方法，确定异常，然后去增加 polyfill 来兼容吧

五、总结

写到这里整篇文章的调试方法就结束了。也许有很多不到位的地方，专业用词不严谨的地方，希望读者和我一起交流。非常乐意我的调试总结给予前端人受用。

Reference

[1]微信开发者工具: https://mp.weixin.qq.com/debug/wxadoc/dev/devtools/download.html

[2]weinre: http://people.apache.org/~pmuellr/weinre/

本文由哈喽比特于2年以前收录，如有侵权请联系我们。
文章来源：https://mp.weixin.qq.com/s/sxBHC2sRIzTUWsZf7x7a-Q