js断点调试心得

1.断点调试是啥？难不难？

断点调试其实并不是多么复杂的一件事，简单的理解无外呼就是打开浏览器，打开sources找到js文件，在行号上点一下罢了。操作起来似乎很简单，其实很多人纠结的是，是在哪里打断点？（我们先看一个断点截图，以chrome浏览器的断点为例）

步骤记住没？

用chrome浏览器打开页面 → 按f12打开开发者工具 → 打开Sources → 打开你要调试的js代码文件 → 在行号上单击一下，OK!恭喜你的处女断点打上了,哈哈~~

2.断点怎么打才合适？

打断点操作很简单，核心的问题在于，断点怎么打才能够排查出代码的问题所在呢？下面我继续举个例子方便大家理解，废话不多说，上图：

假设我们现在正在实现一个加载更多的功能，如上图，但是现在加载更多功能出现了问题，点击以后数据没有加载出来，这时候我们第一时间想到的应该是啥？（换一行写答案，大家可以看看自己的第一反应是啥）

 

我最先想到的是，我点击到底有没有成功？点击事件里的方法有没有运行？好，要想知道这个问题的答案，我们立马去打个断点试试看，断点打在哪？自己先琢磨一下。

接着上图：

各位想到没？没错，既然想知道点击是否成功，我们当然是在代码中的点击事件处添加一个断点，切记不要添加在226行哦，因为被执行的是click方法内的函数，而不是226行的选择器。断点现在已经打上了，然后做什么呢？自己再琢磨琢磨~

继续上图：

然后我们当然是回去点击加载更多按钮啦，为什么？额。。。如果你这么问，请允许我用这个表情，不点击加载更多按钮，怎么去触发点击事件？不触发点击事件，怎么去执行点击事件里的函数？咆哮状。。不过我相信大家肯定不会问这么low的问题~不瞎扯了~

继续正题，上面的图就是点击加载更多按钮后的情况，我们可以看到左侧的页面被一个半透明的层给盖住了，页面上方还有一串英文和两个按钮，右侧代码227行被添加上了背景色，出现这个情况，先不管那些按钮英文是啥意思有啥作用，你从这个图得到了什么信息？继续琢磨琢磨~

如果出现了上图这个情况，说明一点，click事件中的函数被调用了，进一步说明了点击事件生效。那么我们对于这个问题产生的第一个“犯罪嫌疑人”就被排除了。

补充一下：

如果没有出现上面的情况咋办？那是不是说明点击事件没有生效呢？那是什么导致点击事件没有生效？大家自己思考思考~

可能导致点击事件没生效的原因很多，比多选择器错误，语法错误，被选择的元素是后生成的等。怎么解决呢？

选择器错误，大家可以继续往后看到console部分的内容，我想大家就知道怎么处理了

语法错误，细心排查一下，不熟悉的语法可以百度对比一下

被选择的元素是后生成的，最简单的处理就是使用.on()方法去处理，这个东东带有事件委托处理，详情可以自行百度。

那么接下来”犯罪嫌疑人“的身份锁定在哪里呢？

我们将目光投向事件内部，click事件触发了，那么接下来的问题就是它内部的函数问题了。如果你要问为什么？请给我一块豆腐。。。

打个比方，给你一支笔，让你写字，然后你在纸上写了一个字，发现字没出来，为啥？你说我写了呀，纸上都还有划痕。那是不是可能笔没有墨水或者笔尖坏了了？这个例子和点击加载更多一个道理，写字这个动作就是点击操作，而内部函数就是墨水或者笔尖。明白了不~

接着我们分析下点击事件里面的内容，里面包含三句话，第一句话是变量i自增长，第二句话是给按钮添加一个i标签，第三句话是调用请求数据的方法。

就通过这三句话的本身作用，我们可以将较大一部分嫌疑放在第三句话，一小部分放在第一句和第二句话上，有人可能会疑惑，第二句话怎么会有嫌疑呢？他的作用只不过是添加一个标签，对于数据完全没有影响啊，确实，这句话对于数据没有影响，但是出于严谨考虑，它仍然有可能出错，例如它要是少了一个分号呢？或者句子内部某个符号错误呢？往往就是这种小问题浪费我们很多时间。

好，为了进一步锁定”犯罪嫌疑人“，给大家介绍一个工具，也是上图出现两个图标之一，见下图：

这个小图标的功能叫”逐语句执行“或者叫”逐步执行“，这是我个人理解的一个叫法，意思就是，每点击它一次，js语句就会往后执行一句，它还有一个快捷键，F10。下图示范一下它被点击以后的效果：

我单击了两次这个按钮（或者使用F10快捷键），js代码从227行执行到了229行，所以我管它叫”逐语句执行“或者”逐步执行“。这个功能非常的实用，大部分的调试都会使用到它。

太晚了，明天继续写，好戏还在后头~

——————————————————————分割线————————————————————

 

OK，接着写！

上面介绍到我单击了两次“逐语句执行”按钮，代码从227行运行到229行，大家觉得这意味着啥？是不是说明从语法上来说，前两句是没有问题的，那么是不是也同时意味着前两句就排除嫌疑了呢？我看不然。

大家都知道，加载更多就是一个下一页的功能，而其中最核心的一个就是传给后台的页码数值，每当我点击加载更多按钮一次，页码的数值就要加1，所以如果下一页的数据没出来，是不是有可能是因为页码数值也就是[i变量]（下面统一称呼i）有问题？那么如何排查页码是否存在问题呢？大家自己先思考思考。

下面教大家两种查看页码数值i]实际输出值的方法，上图：

第一种：

操作步骤如下：

1.仍然是在227行打上断点 → 2. 点击加载更多按钮 → 3. 单击一次“逐语句执行“按钮，js代码执行到228行 → 4.用鼠标选中i++（什么叫选中大家里不理解？就是你要复制一个东西，是不是要选中它？对，就是这个选中） → 5. 选中以后，鼠标悬浮在目标上方，你就看到上图的结果。

第二种：

这个方法其实和第一种差不多，只不过是在控制台输出i的值，大家只需要按照第一种方法执行到第三步 → 4. 打开和sources同一级栏目的console → 5. 在console下方的输入栏里输入i → 6. 按enter回车键即可。

上面的第二种方法里，提到了console这个东西，我们可以称呼它为控制台或者其他什么都可以，这不重要~console的功能很强大，在调试的过程中，我们往往需要知道某些变量的值到底输出了什么，或者我们使用选择器[$”.div”)这种]是否选中了我们想要的元素等，都可以在控制台打印出来。当然直接用第一种方法也可以。

给大家示范一下在console里打印我们想要选中的元素。上图~

在控制台中输入$(this)，即可得到选择的元素，没错，正是我们所点击的对象——加载更多按钮元素。

在这里给大家说说我对console这个控制台的理解：这个东东就是一个js解析器，是浏览器本身用来解析运行js的家伙，只不过浏览器通过console让我们开发者在调试过程中，可以控制js的运行以及输出。通过上面的两种方法，大家可能觉得使用起来很简单，但是我要给大家提醒一下，或者说是一些新手比较容易遇到的困惑。

困惑一：在没有打断点的情况下，在console输入i，结果console报错了。

这应该是新手很常见的问题，为什么不打断点我就没有办法在控制台直接输出变量的值呢？个人理解这时候i只是一个局部变量，如果不打上断点，浏览器会把所有的js全部解析完成，console并不能访问到局部变量，只能访问到全局变量，所以这时候console会报错i未定义，但是当js打上断点时，console解析到了局部变量i所在的函数内，这时候i是能够被访问的。

困惑二：为什么我直接在console里输入$(“.xxx”)能打印出东西来呢？

很简单，console本身就是一个js解析器，$(“.xxx”)就是一个js语句，所以自然console能够解析这个语句然后输出结果。

介绍完“逐语句执行”按钮和console控制台的用法，最后再介绍一个按钮，上图：

这个按钮我称呼它为“逐过程执行”按钮，和“逐语句执行”按钮不同，“逐过程执行”按钮常用在一个方法调用多个js文件时，涉及到的js代码比较长，则会使用到这个按钮。

上图：

假设上图我只在227行打了个断点，然后一直点击逐语句执行”按钮到229行，这时候如果再点击一次“逐语句执行”按钮呢？则会进入下图的js里：

这些都是zepto库文件的内容，没啥好看的，里面运行很复杂，我们不可能一直使用“逐语句执行”按钮，这样你会发现你按了大半天还在库文件里面绕。。。这时候咋办？那就该“逐过程执行”按钮上场了。

上图：

我除了在227行打了一个断点，同时还在237行打了一个断点，当我们运行到229行时，直接单击“逐过程执行”按钮，你会发现，js直接跳过了库文件，运行到了237行，大家可以自己使用体验一下。

 

最后总结：

本文主要介绍了“逐语句执行”按钮、“逐过程执行”按钮、console控制台这三个工具，以及调试bug时的一些思路。工具的用法我就不再赘述了，大家知道用法就行，具体怎么去更合理的使用，还需要大家通过大量的实践去总结提升~

我其实在本文主要想讲的是调试bug的一个思路，但是由于选的例子涉及东西太多。。。怕全部写下来内容太长，大家也没兴趣看，所以我就简单的选了一部分给大家讲解，不知道大家有没有收获。别看我调试三句话写了一堆的东西，如果真的在实际项目中你也像我这样去做，估计你调试一个Bug的时间会比写一个脚本的时间还长很多。。。在实际情况下，我们应该养成拿到问题的第一时间，自行在脑海中排查问题，找到最有可能出现问题的点，如果没办法迅速的排查出最重要的点，那么你可以使用最麻烦但是很靠谱的方法，利用“逐语句执行”按钮将整个和问题相关的js依次去执行一遍，在执行的过程中，自己也跟着理清思路，同时注意下每个变量的值以及选择器选中的元素是否正确，一般来说，这样做一遍下来，bug都解决的差不多了。

 

所以个人认为，我们调试bug的思路应该是这样的：首先，js是否成功的执行进来；其次，js是否存在逻辑问题，变量问题，参数问题等等；最后，如果上述都没有问题，请仔细查看各种符号。。。

OK~断点就讲到这里~有不明白的同学可以在下面留言~还有如果大家有什么不懂的知识点或者对前端比较困惑的地方，也可以在下面留言，有空的时候我也会继续针对大家的留言写一些文档的哦~

出处：https://www.cnblogs.com/mqfblog/p/5397282.html

补充：http://www.runoob.com/w3cnote/js-debugging-skills.html

前言：调试技巧，在任何一项技术研发中都可谓是必不可少的技能。掌握各种调试技巧，必定能在工作中起到事半功倍的效果。譬如，快速定位问题、降低故障概率、帮助分析逻辑错误等等。而在互联网前端开发越来越重要的今天，如何在前端开发中降低开发成本，提升工作效率，掌握前端开发调试技巧尤为重要。

本文将一一讲解各种前端JS调试技巧，也许你已经熟练掌握，那让我们一起来温习，也许有你没见过的方法，不妨一起来学习，也许你尚不知如何调试，赶紧趁此机会填补空白。

1、骨灰级调试大师Alert

那还是互联网刚刚起步的时代，网页前端还主要以内容展示为主，浏览器脚本还只能为页面提供非常简单的辅助功能的时候。那个时候，网页主要运行在以IE6为主的浏览器中，JS的调试功能还非常弱，只能通过内置于Window对象中的alert方法来调试，那时候看起来应该是这个样子：

需要说明一点，这里看到的效果，并非当年的IE浏览器中看到的效果，而是在高版本IE中的效果。此外，当年貌似还没有这么高级的控制台，而alert的使用也是在真实的页面JS代码中。虽然，alert的调试方式很原始，但当时确实有它不可磨灭的价值，甚至到今天，已然有其用武之地。

2、新一代调试王者Console

随着JS在Web前端中能做的事情越来越多，责任越来越大，而地位也越来越重要。传统的alert调试方式已经渐渐不能满足前端开发的种种场景。而且alert调试方式弹出的调试信息，那个窗口着实不太美观，而且会遮挡部分页面内容，着实有些不太友好。

另一方面，alert的调试信息，必须在程序逻辑中添加类似"alert(xxxxx)"这样的语句，才能正常工作，并且alert会阻碍页面的继续渲染。这就意味着开发人员调试完成后，必须手动清除这些调试代码，实在有些麻烦。

所以，新一代的浏览器Firefox、Chrome，包括IE，都相继推出了JS调试控制台，支持使用类似"console.log(xxxx)"的形式，在控制台打印调试信息，而不直接影响页面显示。以IE为例，它看起来像这样：

好吧，再见丑陋的alert弹出框。而以Chrome浏览器为首的后起之秀，为Console扩展了更丰富的功能：

你以为这样就满足了？Chrome开发团队的想象力实在不得不让人佩服：

好了，稍微多说了一点点题外话。总之，控制台以及浏览器内置Console对象的出现，给前端开发调试带来了极大的便利。

有人会问，这样的调试代码不一样需要在调试完成后进行清理吗？

关于这个问题，如果在使用console对象之前先进性存在性验证，其实不删除也不会对业务逻辑造成破坏。当然，为了代码整洁，在调试完成后，还是应尽可能删除这些与业务逻辑无关的调试代码。

3、JS断点调试

断点，调试器的功能之一，可以让程序中断在需要的地方，从而方便其分析。也可以在一次调试中设置断点，下一次只需让程序自动运行到设置断点位置，便可在上次设置断点的位置中断下来，极大的方便了操作，同时节省了时间。——百度百科

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图看看他的效果：

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)"语句的时候使用此方式。此方式使用不多。

前面介绍到的基本上是我们在日常开发中经常用到的调试手段，运用得当它们也几乎能应对我们日常开发中的几乎所有问题。但是，开发者工具还考虑到了更多的情况，提供更多的断点方式，如图：

5、XHR Breakpoints

这几年前端开发发生了翻天覆地的变化，从当初的名不见经传到如今的盛极一时，Ajax驱动Web富应用，移动WebApp单页应用风生水起。这一切都离不开XMLHttpRequest对象，而"XHR Breakpoints"正是专为异步而生的断点调试功能。

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

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

6、Event Listener Breakpoints

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

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

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