代码调试，别再只会用console、debugger

前言

在日常开发中，随着代码的复杂度不断提升，断点调试已经成为必不可少的工具，尤其是在逆向分析、性能优化和复杂逻辑排查中，能够提供精准的控制和信息获取。然而，在某些特殊场景下，普通的行断点可能无法满足需求，这时候可以尝试更高级的断点类型，例如：

• 条件断点（Conditional Breakpoints）：当变量满足特定条件时才会触发断点，避免不必要的中断，提高调试效率。
• 日志断点：不会在断点的位置断下，但是会在命中日志断点的时候输出一行日志。
• XHR/Fetch 断点：在网络请求发送或响应时暂停代码，帮助分析 API 请求参数、响应数据以及可能的错误。
• DOM 断点：当某个 DOM 节点发生变化（如属性变更、被移除、子元素修改等）时触发，便于排查动态更新的问题。
• 事件监听断点（Event Listener Breakpoints）：可以在特定事件触发时暂停代码，如 click、keydown，适用于调试用户交互逻辑。
• 异常断点（Exception Breakpoints）：当代码抛出错误时立即暂停，帮助迅速定位 bug。

下面就来介绍下各种断点如何使用

正常断点

正常断点，大家可能很熟悉了，在 JS 逆向中，断点是很常用的一种调试手段，只要在想要打断点的行号上轻轻的点一下，断点就打好了。

或者在行号上点击右键，选择断点也可以添加一个断点在指定的位置。

正常断点是蓝色的，这个时候重新刷新页面，如果断点的位置没错的话，JS 就会断在断点的位置，这个时候可以在控制台查看变量的值，甚至可以修改任意变量的值，修改后的值会立即生效。

条件断点

和正常的断点一样，在行号处点击右键，选择条件断点，会弹出一个输入框，输入所需要断下的条件，回车即可。

条件断点的颜色是黄色的，而且会带一个小问号在行号的前面。条件断点只会在条件满足的时候断下，适合在需要特定条件调试的情况下使用。

日志断点

日志断点，它不会在断点的位置断下，但是会在命中日志断点的时候输出一行日志。

打好的断点会变成粉红色，而且在命中断点的时候会输出 pointFeature 的值，在日志的右侧还会输出断点所在的行号。

XHR 断点

XHR 断点可以在任意 XHR 请求发送的时候断下，也可以在包含某些关键字的请求发送的时候断下。

如果想要在包含某个关键字的时候断下，可以点击加号，填写想要断下的关键字即可。

断下时，会自动断在 send 方法的位置，可以看到左侧并没有添加正常断点，而且右侧断点类型的文字会自动变成黄色。

事件断点

在 XHR 断点的下方，有一个事件监听器断点。

它可以对几乎所有的事件下断点，例如鼠标的点击事件，移动事件，双击事件等等，一般用于在事件操作逻辑调试的时候会用到。

选中单击断点后，在页面的任意位置点击一下，会自动触发断点，在控制台也可以打印当前点击的事件源对象e。

DOM 断点

DOM 断点一般用于调试在有新的元素新建、删除、样式改变的时候用。包含子节点修改，属性修改，节点移除断点。

例如我在这里给按钮添加属性修改断点，因为在点击的时候会改变样式。

添加好 DOM 断点后，元素前面会有一个小小的蓝色点点，同时也可以在 DOM 断点的标签中看到已经对哪一个元素添加了 DOM 断点。现在点击按钮试试：

添加好 DOM 断点后，元素前面会有一个小小的蓝色点点，同时也可以在 DOM 断点的标签中看到已经对哪一个元素添加了 DOM 断点。通过对堆栈列表的查看，也可以使用这种方式来查找请求发送的位置。

异常断点

当代码抛出错误时立即暂停，帮助迅速定位异常位置，快速找到bug。

总结

打断点调试是前端开发工程化中的重要技能，能让开发者更精准地分析和修复问题，减少低效的 console.log 调试方式，提高整体开发效率。