一、chrome debug面板
- 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：异常情况自动断点设置。
二、debugger，代码中打断点
所谓的Debugger断点，其实是我自己给它命名的，专业术语我也不知道怎么说。具体的说就是通过在代码中添加"debugger;"语句，当代码执行到该语句的时候就会自动断点。接下去的操作就跟在Sources面板添加断点调试几乎一模一样，唯一的区别在于调试完后需要删除该语句。 既然除了设置断点的方式不一样，功能和Sources面板添加断点效果一样，那么为什么还会存在这种方式呢？我想原因应该是这样的：我们在开发中偶尔会遇到异步加载html片段（包含内嵌JS代码）的情况，而这部分JS代码在Sources树种无法找到，因此无法直接在开发工具中直接添加断点，那么如果想给异步加载的脚本添加断点，此时"debugger;"就发挥作用了。我们直接通过gif图看看他的效果：
三、DOM断点调试
DOM断点，顾名思义就是在DOM元素上添加断点，进而达到调试的目的。而在实际使用中断点的效果最终还是落地到JS逻辑之内。我们依次来看一下每一种DOM断点的具体效果。
1.当节点内部子节点变化时断点（Break on subtree modifications）
通过开发者工具的Elements面板，快速定位到相关DOM节点，这时候通过DOM断点定位脚本。具体我们还是通过gif演示来看一下吧：
2. 当节点属性发生变化时断点（Break on attributes modifications）
另一方面，由于前端处理的业务逻辑越来越复杂，对一些数据的存储依赖越来越强烈，而将临时数据存储于DOM节点的（自定义）属性中，是很多情况下开发者优先选择的方式。特别是在HTML5标准增强自定义属性支持（例：dataset、data-*之类）之后，属性设置应用越来越多，因此Chrome开发者工具也提供了属性变化断点支持，其效果大致如下:
3.当节点被移除时断点（Break on node removal）
这个DOM断点设置很简单，触发方式很明确——当节点被删除时。所以通常情况应该是在执行"parentNode.removeChild(childNode)"语句的时候使用此方式。此方式使用不多。
4.XHR Breakpoints
这几年前端开发发生了翻天覆地的变化，从当初的名不见经传到如今的盛极一时，Ajax驱动Web富应用，移动WebApp单页应用风生水起。这一切都离不开XMLHttpRequest对象，而"XHR Breakpoints"正是专为异步而生的断点调试功能。
我们可以通过"XHR Breakpoints"右侧的"+"号为异步断点添加断点条件，当异步请求触发时的URL满足此条件，JS逻辑则会自动产生断点。演示动画中并没有演示到断点位置，这是因为，演示使用的是jQuery封装好的ajax方法，代码已经过压缩，看不到什么效果，而事实上XHR断点的产生位置是"xhr.send()"语句。
XHR断点的强大之处是可以自定义断点规则，这就意味着我们可以针对某一批、某一个，乃至所有异步请求进行断点设置，非常强大。但是，似乎这个功能在日常开发中用得并不多，至少我用得不多。想想原因大概有两点：其一，这类型的断点调试需求在日常业务中本身涉及不多；其二，现阶段的前端开发大多基于JS框架进行，最基本的jQuery也已经对Ajax进行了良好封装，极少有人自己封装Ajax方法，而项目为了减少代码体积，通常选择压缩后的代码库，使得XHR断点跟踪相对不那么容易了。
5.事件监听器断点，即根据事件名称进行断点设置。当事件被触发时，断点到事件绑定的位置。事件监听器断点，列出了所有页面及脚本事件，包括：鼠标、键盘、动画、定时器、XHR等等。极大的降低了事件方面业务逻辑的调试难度。
