Sizzle引擎的主体部分已经分析完毕了，今天为这部分划一个句号。
a. Sizzle解析流程总结
是时候该做一个总结了。Sizzle解析的流程已经一目了然了。
1.选择器进入Sizzle( selector, context, results, seed )函数，先对选择器不符合要求的（比如没有选择器、选择器不为字符串、上下文环境context不是节点元素且不是document）排除，直接返回；接着判断如果选择器是简单的选择器（只有一个元选择器，比如“#ID”、“.CLASS”、“TAG”等）直接用浏览器支持的函数获取结果返回。接着判断如果浏览器支持高级搜索querySelectorAll且选择器也符合参数标准则获取结果返回。否则进入select( selector, context, results, seed )函数接着处理。
2.进入select( selector, context, results, seed )函数后。select先对选择器selector进行词法解析（tokenize( selector, parseOnly )函数），在没有备选种子seed且选择器并非多个并列选择器（“div >p,input”等用逗号分隔的是并列选择器）的情况下缩小选择范围，包括对原子选择器组tokens的第一个元选择器（最小的选择器）token = tokens[0]为“#ID”且id的下一个token是关系节点（">"/"+"/" "/"~"）的情况先通过Expr.find["ID"]缩小范围（context = Expr.find["ID"](…)）;剩下的tokens的第一给token不是（">"/"+"/"~"）的任何一个且tokens中没有Sizzle自定义的位置伪类(位置伪类有：first、last、even、odd、eq(n)、gt(n)、lt（n）)的情况下，找到最后一个元选择器且保证该元选择器后面没有任何关系选择器，如果找到则根据元选择器查找到备选seed（
seed = find(token.matches[0].replace( runescape, funescape ), rsibling.test( tokens[0].type ) && context.parentNode || context)
），此时如果seed为空或者tokens中没有选择器了则直接返回结果，否则拿着缩小范围的seed继续往下查。进入compile ( selector, group /* Internal Use Only */ )编译好的函数中继续。
3. compile ( selector, group /* Internal Use Only */ )函数最终将返回一个执行终极匹配函数的curry化函数。该curry化函数最终在select函数中执行
compile( selector, match )( seed, context, documentIsXML, results, rsibling.test( selector ))
; compile函数实际就做了两件事情。一件是用tokens生成一个终极匹配函数（cached = matcherFromTokens( group[i] )）压入setMatchers或elementMatchers中。另一件事就是生成并返回执行终极匹配函数的curry化函数（
cached = compilerCache( selector, matcherFromGroupMatchers( elementMatchers, setMatchers ) );
）
4.使用matcherFromTokens生成tokens对应的终极匹配函数。matchers数组用来保存所有匹配函数数组。matchers初始化时有一个默认的匹配函数。从左往右遍历选择器（0-n遍历tokens）如果遇到关系选择器（matcher = Expr.relative[ tokens[i].type ]），则整合关系选择器和原来的matchers生成一个新的匹配函数（matchers = [ addCombinator(elementMatcher( matchers ), matcher) ];）；如果遇到非关系选择器，获取选择器匹配函数（matcher = Expr.filter[ tokens[i].type ].apply( null, tokens[i].matches );），分两种情况处理，一种是伪类选择器则将选择器tokens分成四个部分分别生成相应的匹配函数然后整合直接返回终极匹配函数（
return setMatcher( i > 1 && elementMatcher( matchers ), i > 1 && toSelector( tokens.slice( 0, i - 1 ) ).replace( rtrim, "$1" ), matcher, i < j && matcherFromTokens( tokens.slice( i, j ) ),//如果伪类后面紧跟伪类并列选择器（比如“:first.chua span”）中的".chua" j < len && matcherFromTokens( (tokens = tokens.slice( j )) ),//如果伪类(或伪类并列选择器)还有选择器要筛选
j < len && toSelector( tokens )
);
），另一种是非伪类选择器则将元选择器匹配函数压入matchers中（matchers.push( matcher );）。然后通过elementMatcher( matchers )生成终极匹配函数返回。
5.使用matcherFromGroupMatchers( elementMatchers, setMatchers )返回一个执行终极匹配函数的curry化函数。这个curry化函数内部流程是：先确定起始查找范围，或是seed,或是整个树节点。遍历终极匹配器集合elementMatchers，如果元素匹配则将节点放入结果集中
while ( (matcher = elementMatchers[j++]) ) { if ( matcher( elem, context, xml ) ) { results.push( elem ); break; } }
。然后遍历有伪类选择器的终极匹配函数做相应的处理
while ( (matcher = setMatchers[j++]) ) { matcher( unmatched, setMatched, context, xml ); }
。完成所有流程后把匹配结果返回。
到此基本流程就结束啦。可能内部有些小细节没有深究明白，但是流程已经OK了。希望大家有所收获，哈哈。
b. 选择器效率问题
一般来说浏览器原生函数效率getElementById > getElementsByTagName >= getElementsByClassName。测试结果
测试案例(借用Arron的测试案例)
<div class='demo'> <ul> <li><input type="checkbox" data="data"/></li> <li></li > <li> </li> <li></li > </ul> </div >
第一组测试：连续书写、分段书写、使用find方式比较: https://jsperf.com/jquerywrite/1
和Arron测试的结果不同：aaron的测试结果在点击这里查看
可见Arron测试的jquery版本比较低，没有做开头是id选择器的优化。高版本就没有这个问题了。
我根据jQuery的源码推测一下：
分两种情况：
第一种，支持querySelectorAll下
$('#demo li:nth-child(1)') 方式Sizzle会先直接使用querySelectorAll查询'#demo li:nth-child(1)'
$('li:nth-child(1)','#demo')方式先$('#demo')得到结果作为context进入Sizzle使用querySelectorAll查询'li:nth-child(1)'。比第一种多走一步
$('.demo').find('li:nth-child(1)')方式和$('li:nth-child(1)','#demo')类似，效率应该差不多。
第二种，不支持querySelectorAll的情况下（我用IE7测试），用自己的测试方法（jsperf有兼容问题）
测试方法（定时10秒看执行次数） <script type="text/javascript"> var dateStart,dateEnd, count = 0; //这是其中一个案例 function testID(){ dateStart = new Date(); count = 0; while(1){ dateEnd = new Date(); if(dateEnd - dateStart > 10000){ console.log('#demo li:nth-child(1) run count = ' + count); break; } $('#demo li:nth-child(1)'); count++; } }