這是第一組終極匹配器的生成流程了，可見過程極其復雜，被包裝了三層，依次：
addCombinator elementMatcher Expr.relative
三個方法嵌套處理出來的結構：
然后繼續分解下一組，遇到關系選擇器又繼續依照以上的過程分解，但是有一個不同的地方，下一個分組會把上一個分組給一并合并了。
所以整個關系就是一個依賴嵌套很深的結構，最終暴露出來的終極匹配器其實只有一個閉包，但是有內嵌很深的分組閉包了，依照從左邊往右依次生成閉包，然后把上一組閉包又push到下一組閉包。
就跟棧是一種后進先出的數據結構一樣處理了，所以在最外層也就是：
type=["checkbox"]
我們回到superMatcher方法的處理了，在遍歷seed種子合集，依次匹配matchers閉包函數，傳入每一個seed的元素與之匹配（這里就是input），在對應的編譯處理器中通過對input的處理，找到最優匹配結果：
function( elem, context, xml ) {
var i = matchers.length;
while ( i-- ) {
if ( !matchers[i]( elem, context, xml ) ) {
return false;
}
}
return true;
} :
這里注意了，是i--，從后往前找，所以第一次開始匹配的就是：
check: "checkbox" name: "type" operator: "="
那么就找到對應的Attr處理方法：
Sizzle.attr( elem, name )
傳入elem元素就是seed中的input元素，找到是否有'type'類型的屬性，比如：
<input type="text">"
所以第一次匹配input就出錯了，返回的type是text，而不是我們需要的'checkbox'，這里返回的結果就是false，所以整個之后的處理就直接return了，繼續拿出第二個input。
繼續上一個流程，這時候發現檢測到的屬性：
var result = Sizzle.attr( elem, name ); result: "checkbox"
此時滿足第一條匹配，然后繼續 i = 0
!matchers[i]( elem, context, xml )
找到第0個編譯函數：
addCombinator
如果是不緊密的位置關系，那么一直匹配到true為止，如祖宗關系的話，就一直找父親節點直到有一個祖先節點符合規則為止。
直接遞歸調用：
matcher( elem, context, xml )
其實就是下一組閉包隊列了，傳入的上下文是 div.aaron，也就是<input type="checkbox">的父節點：
function (elem, context, xml) {
var i = matchers.length;
//從右到左開始匹配
while (i--) {
//如果有一個沒匹配中，那就說明該節點elem不符合規則
if (!matchers[i](elem, context, xml)) {
return false;
}
}
return true;
}
依照上面的規則，這樣遞歸下去了，一層一層的匹配，可見它原來不是一層一層往下查，卻有點倒回去向上做匹配、過濾的意思。Expr里面只有find和preFilter返回的是集合。
盡管到這里暫時還帶著一點疑問，但是我想Sizzle最基本的“編譯原理”應該已經解釋清楚了。
請驗證，完成請求
由于請求次數過多，請先驗證，完成再次請求
打開微信掃碼自動綁定
綁定后可得到
使用 Ctrl+D 可將課程添加到書簽
舉報