前端JS调试技巧全解析：从Console到断点实战

前端JS调试技巧全解析：从Console到断点实战

前言：编程工作中，调试代码是不可或缺的一环，无论开发者经验高低，这都是必须掌握的技能。通常，调试发生在代码编写完成或测试阶段修复Bug时，这一过程往往最能体现开发者的技术水准和问题分析能力。许多初学者在排查错误时容易迷失方向，耗费大量时间却难以解决一些本应简单的Bug。熟练掌握各类调试技巧，能显著提升工作效率，例如快速定位问题、降低故障率以及辅助分析逻辑错误。随着互联网前端开发的重要性日益凸显，掌握高效的前端调试技巧对于降低成本、提升开发效率至关重要。

本文将详细介绍多种前端JS调试技巧。如果你已熟悉这些方法，不妨借此温习；若遇到未掌握的技巧，欢迎一起学习；若你对调试尚感陌生，这正是填补知识空白的绝佳机会。

经典调试方式：Alert

1、经典调试方式：Alert

在互联网发展初期，网页前端主要侧重于内容展示，浏览器脚本仅能提供简单的辅助功能。当时，网页主要运行在IE6等浏览器中，JS的调试功能极为有限，开发者只能依赖内置于Window对象中的alert方法进行调试。当时的调试场景大致如下：

需要说明的是，图中展示的效果并非当年IE浏览器中的真实表现，而是高版本IE中的效果。此外，当年尚未出现如今这样高级的控制台，alert的使用是直接嵌入在页面JS代码中的。尽管alert调试方式显得原始，但在当时具有不可替代的价值，即便在今天，它在某些特定场景下仍有一席之地。

现代调试主力：Console

2、现代调试主力：Console

随着JS在Web前端承担的功能和责任日益增加，其地位愈发重要。传统的alert调试方式已逐渐无法满足前端开发的多样化需求。此外，alert弹出的窗口不仅外观不够美观，还会遮挡页面内容，体验较差。

另一方面，使用alert调试需要在程序逻辑中显式添加类似"alert(xxxxx)"的代码才能生效，且alert会阻塞页面的后续渲染。这意味着开发人员在调试结束后，必须手动清除这些调试代码，操作较为繁琐。

因此，Firefox、Chrome以及IE等新一代浏览器相继推出了JS调试控制台，支持通过"console.log(xxxx)"的形式在控制台打印调试信息，且不会直接影响页面显示。以IE为例，其界面大致如下：

至此，告别了丑陋的alert弹出框。而以Chrome浏览器为代表的现代浏览器，为Console扩展了更丰富的功能：

Chrome开发团队的创新令人印象深刻：

简要介绍这些额外功能。总之，控制台及浏览器内置Console对象的出现，极大地便利了前端开发调试工作。

有人可能会问，使用Console调试的代码是否也需要在调试完成后清理？

关于此问题，如果在调用console对象前先进行存在性验证，即使不删除这些代码，通常也不会对业务逻辑造成破坏。当然，为了保持代码整洁，建议在调试完成后尽可能删除这些与业务逻辑无关的调试代码。

JS断点调试

3、JS断点调试

断点是调试器的核心功能之一，它允许程序在指定位置暂停，从而方便开发者进行分析。设置断点后，程序下次运行至该位置时会自动中断，无需重新手动触发，这极大地简化了操作流程并节省了时间。——百度百科

JS断点调试即在浏览器开发者工具中为JS代码添加断点，使程序执行到特定位置时暂停，便于开发者分析该处代码段及逻辑。为了演示断点调试效果，我们预先准备一段JS代码：

这段代码很简单，定义了一个函数，接收两个参数，分别加上一个随机整数后，返回这两个数的总和。以Chrome开发者工具为例，我们来看JS断点调试的基本操作方法。

3.1、Sources面板断点

首先，通过上图console的输出结果可以看出代码似乎正常运行，但为何说是“似乎”呢？因为函数中加入了随机数，最终结果是否正确尚不确定。这种猜测毫无意义，但假设我们需要验证：函数传入的两个数、被加的随机数以及最终的总和，该如何操作？

方法一，如前所述，无论是使用alert还是console，我们可以通过以下方式验证：

从上图可以看出，我们在代码中新增了三行console代码，用于打印我们关心的数据变量。最终，通过控制台（Console面板）的输出结果，我们可以清晰地验证整个计算过程是否正常，从而满足题设的验证要求。

方法二，方法一的验证过程存在明显弊端，即添加了冗余代码。接下来我们看看使用断点进行验证是否更为便捷。首先演示如何添加断点及其效果：

如图，添加断点的流程为：“F12（Ctrl + Shift + I）打开开发工具”——“点击Sources菜单”——“在左侧树状结构中查找相应文件”——“点击行号列”即可完成在当前行添加/删除断点操作。断点添加完毕后，刷新页面，JS执行到断点位置时会自动停止。在Sources界面中，你可以看到当前作用域中的所有变量及其值，只需验证每个值即可满足题设要求。

这里有一个问题：细心的朋友会发现，当代码执行到断点时，显示的变量a和b的值已经是进行加法运算后的结果，我们无法看到调用sum函数时初始传入的10和20。该怎么办呢？这需要我们先学习一些断点调试的基础知识。打开Sources面板后，你会看到如下界面，我们跟随鼠标轨迹逐一了解各功能键的含义：

从左到右，各个图标表示的功能分别为：

Pause/Resume script execution：暂停/恢复脚本执行（程序执行到下一断点停止）。

Step over next function call：执行到下一步的函数调用（跳到下一行）。

Step into next function call：进入当前函数。

Step out of current function：跳出当前执行函数。

Deactive/Active all breakpoints：关闭/开启所有断点（不会取消）。

Pause on exceptions：异常情况自动断点设置。

至此，断点调试的功能键介绍基本完成。接下来，我们可以逐行查看程序代码，观察每一行执行完毕后各个变量的变化情况，如下图所示：

如上所示，我们可以清晰地看到a、b变量从初始值，到中间加上随机值，再到最后计算总和并输出最终结果的整个过程，轻松完成题设验证要求。

对于其他几个功能键，我们稍微改动测试代码，通过一张gif图演示其使用方法：

这里需要注意一点：直接在代码区打印变量值的功能是在较新版本的Chrome浏览器中才新增的。如果你仍在使用较老版本的Chrome浏览器，可能无法直接在断点状态下查看变量信息。此时，你可以将鼠标悬停在变量名上短暂停留，即可看到变量值。或者，选中变量名称后右键选择“Add to watch”，在Watch面板中查看，此方法同样适用于表达式。此外，你还可以在断点状态下切换到Console面板，直接在控制台输入变量名称并回车查看变量信息。这部分内容较为简单，考虑到篇幅，不再做图演示。

3.2、Debugger断点

所谓的Debugger断点，是我个人的命名，专业术语暂不明确。具体来说，就是在代码中添加"debugger;"语句，当程序执行到该语句时会自动触发断点。后续操作与在Sources面板添加断点调试几乎完全相同，唯一的区别在于调试完成后需要手动删除该语句。

既然除了设置断点的方式不同，功能和Sources面板添加断点的效果一致，那么为何还存在这种方式呢？我认为原因如下：在开发过程中，我们偶尔会遇到异步加载HTML片段（包含内嵌JS代码）的情况，这部分JS代码在Sources树中无法找到，因此无法直接在开发工具中添加断点。此时，若想给异步加载的脚本添加断点，“debugger;”语句便派上了用场。我们直接通过gif图查看其效果：

DOM断点调试

4、DOM断点调试

DOM断点，顾名思义，即在DOM元素上添加断点，以达到调试目的。在实际使用中，断点的效果最终仍体现在JS逻辑中。我们依次来看一下每种DOM断点的具体效果。

4.1、当节点内部子节点变化时断点（Break on subtree modifications）

在前端开发日益复杂的今天，前端JS代码量庞大且逻辑复杂。一个看似简单的Web页面，通常伴随着大段JS代码，涉及诸多DOM节点的增、删、改操作。难免遇到通过JS代码难以直接定位代码段的情况，而通过开发者工具的Elements面板快速定位相关DOM节点后，利用DOM断点定位脚本就显得尤为重要。具体效果仍通过gif演示：

上图演示了对ul子节点（li）的增加、删除以及交换顺序操作触发断点的效果。但需要注意的是，对子节点进行属性修改和内容修改并不会触发断点。

4.2、当节点属性发生变化时断点（Break on attributes modifications）

另一方面，由于前端处理的业务逻辑日益复杂，对数据存储的依赖越来越强。将临时数据存储于DOM节点的（自定义）属性中，是许多情况下开发者的优先选择。特别是在HTML5标准增强了对自定义属性的支持（例如：dataset、data-*等）之后，属性设置的应用越来越广泛。因此，Chrome开发者工具也提供了属性变化断点支持，其效果大致如下：

此方式同样需要注意：对子节点的属性进行任何操作也不会触发节点本身的断点。

4.3、当节点被移除时断点（Break on node removal）

这个DOM断点设置相对简单，触发方式明确——当节点被删除时触发。因此，通常在执行"parentNode.removeChild(childNode)"语句时使用此方式。此功能在日常开发中使用频率不高。

前面介绍的大多是日常开发中常用的调试手段，运用得当几乎能应对日常开发中的绝大多数问题。但是，开发者工具还考虑到了更多情况，提供了更多的断点方式，如图：

XHR Breakpoints

5、XHR Breakpoints

近年来，前端开发发生了翻天覆地的变化，从默默无闻到如今的主流地位，Ajax驱动的Web富应用和移动WebApp单页应用蓬勃发展。这一切都离不开XMLHttpRequest对象，而“XHR Breakpoints”正是专为异步请求设计的断点调试功能。

我们可以通过“XHR Breakpoints”右侧的“+”号为异步断点添加断点条件。当异步请求触发的URL满足此条件时，JS逻辑会自动产生断点。演示动画中并未显示断点位置，这是因为演示使用的是jQuery封装好的ajax方法，代码经过压缩，无法直观看到效果。事实上，XHR断点的产生位置是“xhr.send()”语句。

XHR断点的强大之处在于可以自定义断点规则，这意味着我们可以针对某一批、某一个乃至所有异步请求进行断点设置，功能非常强大。然而，这个功能在日常开发中使用频率似乎不高，至少我很少使用。究其原因大概有两点：其一，这类断点调试需求在日常业务中本身涉及不多；其二，现阶段的前端开发大多基于JS框架进行，最基本的jQuery也已经对Ajax进行了良好封装，极少有人自己封装Ajax方法。此外，项目为了减少代码体积，通常选择压缩后的代码库，使得XHR断点跟踪相对不那么容易。

Event Listener Breakpoints

6、Event Listener Breakpoints

事件监听器断点，即根据事件名称进行断点设置。当事件被触发时，程序会断点到事件绑定的位置。事件监听器断点列出了所有页面及脚本事件，包括：鼠标、键盘、动画、定时器、XHR等。这极大地降低了事件方面业务逻辑的调试难度。

演示实例展示了当click事件被触发时和当setTimeout被设置时的断点效果。实例显示，当选中click事件断点之后，两个按钮被点击时都触发了断点；而当setTimeout被设置时，“Set Timer”断点被触发。

调试是项目开发中至关重要的环节，它不仅帮助我们快速定位问题，还能节省开发时间。熟练掌握各种调试手段，必将为你的职业发展带来诸多益处。然而，在如此多的调试手段中，如何选择一个适合自己当前应用场景的方法，这需要经验，需要不断尝试和积累。

写到这里，基本上可以说是倾囊相授。希望能引起你的注意，让你感到一丝触动或似曾相识。最重要的是，我希望你能快速提高自己的技能，成长为技术专家！