困惑二：为什么我直接在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都解决的差不多了。