前言: 调试技巧, 在任何一项技术研发中都可谓是必不可少的技能. 掌握各种调试技巧, 必定能在工作中起到事半功倍的效果. 譬如, 快速定位问题, 降低故障概率, 帮助分析逻辑错误等等. 而在互联网前端开发越来越重要的今天, 如何在前端开发中降低开发成本, 提升工作效率, 掌握前端开发调试技巧尤为重要.
本文将一一讲解各种前端 JS 调试技巧, 也许你已经熟练掌握, 那让我们一起来温习, 也许有你没见过的方法, 不妨一起来学习, 也许你尚不知如何调试, 赶紧趁此机会填补空白.
骨灰级调试大师 Alert
那还是互联网刚刚起步的时代, 网页前端还主要以内容展示为主, 浏览器脚本还只能为页面提供非常简单的辅助功能的时候. 那个时候, 网页主要运行在以 IE6 为主的浏览器中, JS 的调试功能还非常弱, 只能通过内置于 Window 对象中的 alert 方法来调试, 那时候看起来应该是这个样子:
Alert 调试效果
需要说明一点, 这里看到的效果, 并非当年的 IE 浏览器中看到的效果, 而是在高版本 IE 中的效果. 此外, 当年貌似还没有这么高级的控制台, 而 alert 的使用也是在真实的页面 JS 代码中. 虽然, alert 的调试方式很原始, 但当时确实有它不可磨灭的价值, 甚至到今天, 已然有其用武之地.
新一代调试王者 Console
随着 JS 在 web 前端中能做的事情越来越多, 责任越来越大, 而地位也越来越重要. 传统的 alert 调试方式已经渐渐不能满足前端开发的种种场景. 而且 alert 调试方式弹出的调试信息, 那个窗口着实不太美观, 而且会遮挡部分页面内容, 着实有些不太友好.
注: 关于 Console 相关 API 可以查看:
Console API 与命令行
使用 console.table()调试 javascript
美化 console.log 的文本
另一方面, alert 的调试信息, 必须在程序逻辑中添加类似 "alert(xxxxx)" 这样的语句, 才能正常工作, 并且 alert 会阻碍页面的继续渲染. 这就意味着开发人员调试完成后, 必须手动清除这些调试代码, 实在有些麻烦.
所以, 新一代的浏览器 Firefox,Chrome, 包括 IE, 都相继推出了 JS 调试控制台, 支持使用类似 "console.log(xxxx)" 的形式, 在控制台打印调试信息, 而不直接影响页面显示. 以 IE 为例, 它看起来像这样:
Console 调试效果
好吧, 再见丑陋的 alert 弹出框. 而以 Chrome 浏览器为首的后起之秀, 为 Console 扩展了更丰富的功能:
更丰富的 Console
你以为这样就满足了? Chrome 开发团队的想象力实在不得不让人佩服:
花式 Console.log
好了, 稍微多说了一点点题外话. 总之, 控制台以及浏览器内置 Console 对象的出现, 给前端开发调试带来了极大的便利.
有人会问, 这样的调试代码不一样需要在调试完成后进行清理吗?
关于这个问题, 如果在使用 console 对象之前先进性存在性验证, 其实不删除也不会对业务逻辑造成破坏. 当然, 为了代码整洁, 在调试完成后, 还是应尽可能删除这些与业务逻辑无关的调试代码.
JS 断点调试
断点, 调试器的功能之一, 可以让程序中断在需要的地方, 从而方便其分析. 也可以在一次调试中设置断点, 下一次只需让程序自动运行到设置断点位置, 便可在上次设置断点的位置中断下来, 极大的方便了操作, 同时节省了时间.-- 百度百科
JS 断点调试, 即是在浏览器开发者工具中为 JS 代码添加断点, 让 JS 执行到某一特定位置停住, 方便开发者对该处代码段的分析与逻辑处理. 为了能够观察到断点调试的效果, 我们预先随意准备一段 JS 代码:
断点调试测试代码
代码很简单, 就是定义一个函数, 传入两个数, 分别加上一个乱七八糟的随机整数后, 再返回两个数的总和. 以 Chrome 开发者工具为例, 我们来看一下 JS 断点调试的基本方法.
Sources 断点
首先, 测试代码中我们通过上图 console 的输出结果可以看出代码应该是正常运行了, 但是为什么是应该呢? 因为函数中加了一个随机数, 而最终结果是否真的是正确的呢? 这是毫无意义的猜想, 但是假设我现在就是要验证一下: 函数传入的两个数, 被加的随机数, 以及最终的总和. 那么该怎么操作呢?
方法一, 前面讲过最普通的, 无论使用 alert 还是 console, 我们可以这么来验证:
通过 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 面板, 直接在控制台输入变量名称, 回车查看变量信息. 该部分比较简单, 考虑篇幅问题, 不在做图演示.
Debugger 断点
所谓的 Debugger 断点, 其实是我自己给它命名的, 专业术语我也不知道怎么说. 具体的说就是通过在代码中添加 "debugger;" 语句, 当代码执行到该语句的时候就会自动断点. 接下去的操作就跟在 Sources 面板添加断点调试几乎一模一样, 唯一的区别在于调试完后需要删除该语句.
既然除了设置断点的方式不一样, 功能和 Sources 面板添加断点效果一样, 那么为什么还会存在这种方式呢? 我想原因应该是这样的: 我们在开发中偶尔会遇到异步加载 html 片段 (包含内嵌 JS 代码) 的情况, 而这部分 JS 代码在 Sources 树种无法找到, 因此无法直接在开发工具中直接添加断点, 那么如果想给异步加载的脚本添加断点, 此时 "debugger;" 就发挥作用了. 我们直接通过 gif 图看看他的效果:
Debugger 断点使用演示
DOM 断点调试
DOM 断点, 顾名思义就是在 DOM 元素上添加断点, 进而达到调试的目的. 而在实际使用中断点的效果最终还是落地到 JS 逻辑之内. 我们依次来看一下每一种 DOM 断点的具体效果.
当节点内部子节点变化时断点(Break on subtree modifications)
在前端开发越来越复杂的今天, 前端 JS 代码越来越多, 逻辑越来越复杂, 一个看似简单的 Web 页面, 通常伴随着大段大段的 JS 代码, 涉及诸多 DOM 节点增, 删, 改的操作. 难免遇到直接通过 JS 代码很难定位代码段的情况, 而我们却可以通过开发者工具的 Elements 面板, 快速定位到相关 DOM 节点, 这时候通过 DOM 断点定位脚本就显得尤其重要了. 具体我们还是通过 gif 演示来看一下吧:
子节点发生变化时断点
上图演示了对 ul 子节点 (li) 的增加, 删除以及交换顺序操作触发断点的效果. 但需要注意的是, 对子节点进行属性修改和内容修改并不会触发断点.
当节点属性发生变化时断点(Break on attributes modifications)
另一方面, 由于前端处理的业务逻辑越来越复杂, 对一些数据的存储依赖越来越强烈, 而将临时数据存储于 DOM 节点的 (自定义) 属性中, 是很多情况下开发者优先选择的方式. 特别是在 HTML5 标准增强自定义属性支持 (例: dataset,data-* 之类) 之后, 属性设置应用越来越多, 因此 Chrome 开发者工具也提供了属性变化断点支持, 其效果大致如下:
节点属性变化时断点演示
此方式同样需要注意, 对子节点的属性进行任何操作也不会触发节点本身的断点.
当节点被移除时断点(Break on node removal)
这个 DOM 断点设置很简单, 触发方式很明确 -- 当节点被删除时. 所以通常情况应该是在执行 "parentNode.removeChild(childNode)" 语句的时候使用此方式. 此方式使用不多.
前面介绍到的基本上是我们在日常开发中经常用到的调试手段, 运用得当它们也几乎能应对我们日常开发中的几乎所有问题. 但是, 开发者工具还考虑到了更多的情况, 提供更多的断点方式, 如图:
XHR 和事件监听断点
XHR Breakpoints
这几年前端开发发生了翻天覆地的变化, 从当初的名不见经传到如今的盛极一时, Ajax 驱动 Web 富应用, 移动 WebApp 单页应用风生水起. 这一切都离不开 XMLHttpRequest 对象, 而 "XHR Breakpoints" 正是专为异步而生的断点调试功能.
XHR Breakpoints 演示
我们可以通过 "XHR Breakpoints" 右侧的 "+" 号为异步断点添加断点条件, 当异步请求触发时的 URL 满足此条件, JS 逻辑则会自动产生断点. 演示动画中并没有演示到断点位置, 这是因为, 演示使用的是 jQuery 封装好的 ajax 方法, 代码已经过压缩, 看不到什么效果, 而事实上 XHR 断点的产生位置是 "xhr.send()" 语句.
XHR 断点的强大之处是可以自定义断点规则, 这就意味着我们可以针对某一批, 某一个, 乃至所有异步请求进行断点设置, 非常强大. 但是, 似乎这个功能在日常开发中用得并不多, 至少我用得不多. 想想原因大概有两点: 其一, 这类型的断点调试需求在日常业务中本身涉及不多; 其二, 现阶段的前端开发大多基于 JS 框架进行, 最基本的 jQuery 也已经对 Ajax 进行了良好封装, 极少有人自己封装 Ajax 方法, 而项目为了减少代码体积, 通常选择压缩后的代码库, 使得 XHR 断点跟踪相对不那么容易了.
Event Listener Breakpoints
事件监听器断点, 即根据事件名称进行断点设置. 当事件被触发时, 断点到事件绑定的位置. 事件监听器断点, 列出了所有页面及脚本事件, 包括: 鼠标, 键盘, 动画, 定时器, XHR 等等. 极大的降低了事件方面业务逻辑的调试难度.
事件监听器断点演示
演示实例演示了当 click 事件被触发时和当 setTimeout 被设置时的断点效果. 实例显示, 当选中 click 事件断点之后, 两个按钮的被点击时都触发了断点, 而当 setTimeout 被设置时,"Set Timer" 断点被触发.
调试, 是在项目开发中非常重要的环节, 不仅可以帮助我们快速定位问题, 还能节省我们的开发时间. 熟练掌握各种调试手段, 定当为你的职业发展带来诸多利益, 但是, 在如此多的调试手段中, 如何选择一个适合自己当前应用场景的, 这需要经验, 需要不断尝试积累.
来源: http://www.qdfuns.com/article/26579/b19270c87c48064a133a00656cc3ed3d.html