superMatcher方法会根据参数seed、expandContext和context确定一个起始的查询范围，有可能是直接从seed中查询过滤，也有可能在context或者context的父节点范围内。如果不是从seed开始，那么它会先执行Expr.find["TAG"]( "*", expandContext && context.parentNode || context )这句代码等到一个elems集合（数组）。然后对elems做一个遍历，对里面的元素逐个使用预先生成的matcher方法做匹配，如果结果为true的则直接将元素堆入返回结果集里面。
好吧，看到这里matcher方法原来运行的结果都是bool值，我们再返回405行看一下Expr里面filter包含的方法，都是返回bool值的。包括PSEUDO（伪类）对应的更多的伪类方法都一样。似乎有点颠覆我最初的设想，它原来不是一层一层往下查，却有点倒回去向上做匹配、过滤的意思。Expr里面只有find和preFilter返回的是集合。
尽管到这里暂时还带着一点疑问，就是最后它为什么用的是逐个匹配、过滤的方法来得到结果集，但是我想Sizzle最基本的“编译原理”应该已经解释清楚了。
但是疑问不能留着，我们继续。其实这篇文章本身已经有点倒过来写的味道了。有兴趣看源码的同学不会一开始就看到这三个关键的方法。实际上Sizzle在进入这三个方法之前，还做了一系列的其他工作。
Sizzle的真正入口可以说是在源码的220行：
复制代码 代码如下:
function Sizzle( selector, context, results, seed ){ }
这个方法前面一段比较容易懂，如果能匹配到selector是单一的ID选择符（#id），则先根据id就直接用context.getElementById( m )方法把元素找出来。如果能匹配到selector是单一的TAG选择符，也先直接用context.getElementsByTagName( selector )方法把相关的元素找出来。如果当前浏览器只是原生的getElementsByClassName，并且匹配到selector是单一的CLASS选择符，也会也用context.getElementsByClassName( m )方法把相关的元素找出来。这个三个方法，都是浏览器支持的原生方法，执行效率肯定是最高的。
如果最基本的方法都用不上的话，才会进入到select方法。源码1480行有它的定义：
复制代码 代码如下:
function select( selector, context, results, seed, xml ) { }
在select方法里面，首先会对selector做我们前面提到的“分词”操作。但是这个操作之后并没有直接开始组装匹配方法，而是先做了一些find的操作。这里的find操作就可以对应到Expr里面的find，它执行的是查询操作，返回的是结果集。
可以这样理解，select利用“分词”得到的选择符根据它的type先将可以用find方法查找的结果集查出来。做find操作的时候，是按照选择符的顺序从左到右缩小结果集范围的。如果一个遍历下来，selector中的所有选择符都可以执行find操作，则直接将结果返回。否则，就进入前面介绍的“编译”执行过滤的流程了。
到这里，也可以顺过来，基本上理清楚Sizzle的工作流程了。前面留下的疑问到此时其实也不算疑问了，因为执行反向匹配过滤的时候，它的查找范围已经是经过层层过滤的最小集合了。而反向匹配过滤的方法对于它所对应的那些选择符，比如伪类之类的，其实也已经是一个高效的选择。
再来简单总结为什么Sizzle很高效。
首先，从处理流程上，它总是先使用最高效的原生方法来做处理。前面一直在介绍的还只是Sizzle自身的选择器实现方法，真正Sizzle执行的时候，它还会先判断当前浏览器是否支持querySelectorAll原生方法（源代码1545行）。如果支持的话，则优先选用此方法，浏览器原生支持的方法，效率肯定比Sizzle自己js写的方法要高，优先使用也能保证Sizzle更高的工作效率。（关于querySelectorAll可以上网查阅更多资料）。在不支持querySelectorAll方法的情况下，Sizzle也是优先判断是不是可以直接使用getElementById、getElementsByTag、getElementsByClassName等方法解决问题。
其次，相对复杂的情况，Sizzle总是选择先尽可能利用原生方法来查询选择来缩小待选范围，然后才会利用前面介绍的“编译原理”来对待选范围的元素逐个匹配筛选。进入到“编译”这个环节的工作流程有些复杂，效率相比前面的方法肯定会稍低一些，但Sizzle在努力尽量少用这些方法，同时也努力让给这些方法处理的结果集尽量小和简单，以便获得更高的效率。
再次，即便进入到这个“编译”的流程，Sizzle还做了我们前面为了优先解释清楚流程而暂时忽略、没有介绍的缓存机制。源代码1535行是我们所谓的“编译”入口，也就是它会调用第三个核心方法superMatcher。跟踪进去看1466行，compile方法将根据selector生成的匹配函数缓存起来了。还不止如此，再到1052行看tokenize方法，它其实也将根据selector做的分词结果缓存起来了。也就是说，当我们执行过一次Sizzle (selector)方法以后，下次再直接调用Sizzle (selector)方法，它内部最耗性能的“编译”过程不会再耗太多性能了，直接取之前缓存的方法就可以了。我在想所谓“编译”的最大好处之一可能也就是便于缓存，所谓“编译”在这里可能也就可以理解成是生成预处理的函数存储起来备用。