jQuery是總?cè)肟冢x擇器支持9種方式的處理
(1)基本
#id
element
.class
*
selector1,selector2,selectorN
(2)層次選擇器：
ancestor descendant
parent > child
prev + next
prev ~ siblings
(3)基本過濾器選擇器
:first
:last
:not
:even
:odd
:eq
:gt
:lt
:header
:animated
(4)內(nèi)容過濾器選擇器
:contains
:empty
:has
:parent
(5)可見性過濾器選擇器
:hidden
:visible
(6)屬性過濾器選擇器
[attribute]
[attribute=value]
[attribute!=value]
[attribute^=value]
[attribute$=value]
[attribute*=value]
[attrSel1][attrSel2][attrSelN]
(7)子元素過濾器選擇器
:nth-child
:first-child
:last-child
:only-child
(8)表單選擇器
:input
:text
:password
:radio
:checkbox
:submit
:image
:reset
:button
:file
:hidden
(9)表單過濾器選擇器
:enabled
:disabled
:checked
:selected
jQuery查詢的的對象是dom元素，查詢到目標元素后，如何存儲？
查詢的到結(jié)果儲存到j(luò)Query對象內(nèi)部，由于查詢的dom可能是單一元素，也可能是合集
jQuery內(nèi)部應(yīng)該要定義一個合集數(shù)組，用于存在選擇后的dom元素，
當然啦，根據(jù)API，jQuery構(gòu)建的不僅僅只是DOM元素，還有HTML字符串,Object,[] 等等…
ownerDocument和documentElement的區(qū)別
- ownerDocument是Node對象的一個屬性，返回的是某個元素的根節(jié)點文檔對象：即document對象
- documentElement是Document對象的屬性，返回的是文檔根節(jié)點
- 對于HTML文檔來說，documentElement是<html>標簽對應(yīng)的Element對象，ownerDocument是document對象
jQuery.parseHTML
使用原生的DOM元素的創(chuàng)建函數(shù)將字符串轉(zhuǎn)換為一組DOM元素，然后，可以插入到文檔中。
str = "hello, <b>my name is</b> jQuery.",
html = $.parseHTML( str ),
~jQuery 構(gòu)造器~
從本質(zhì)上來說，構(gòu)建的jQuery對象，其實不僅僅只是dom，還有很多附加的元素，用數(shù)組的方式存儲，當然各種組合有不一樣，但是存儲的方式是一樣的
總的來說分2大類：
單個DOM元素，如$(ID),直接把DOM元素作數(shù)組傳遞給this對象
多個DOM元素，集合形式，可以通過CSS選擇器匹配是有的DOM元素，過濾操作,構(gòu)建數(shù)據(jù)結(jié)構(gòu)
CSS選擇器是通過jQuery.find(selector)函數(shù)完成的，通過它可以分析選擇器字符串，并在DOM文檔樹中查找符合語法的元素集合
為什么排版引擎解析CSS選擇器時一定要從右往左解析
而如果按從左到右的方式進行查找
- 先找到所有div節(jié)點
- 第一個div節(jié)點內(nèi)找到所有的子div,并且是class=”Aaron”
- 然后再一次匹配p span.red等情況
- 遇到不匹配的情況，就必須回溯到一開始搜索的div或者p節(jié)點，然后去搜索下個節(jié)點，重復(fù)這樣的過程。這樣的搜索過程對于一個只是匹配很少節(jié)點的選擇器來說，效率是極低的，因為我們花費了大量的時間在回溯匹配不符合規(guī)則的節(jié)點。
如果換個思路，我們一開始過濾出跟目標節(jié)點最符合的集合出來，再在這個集合進行搜索，大大降低了搜索空間
從右到左來解析選擇器
則首先就查找到<span class='red'>的元素。
firefox稱這種查找方式為key selector(關(guān)鍵字查詢)，所謂的關(guān)鍵字就是樣式規(guī)則中最后(最右邊)的規(guī)則，上面的key就是span.red。
緊接著我們判斷這些節(jié)點中的前兄弟節(jié)點是否符合p這個規(guī)則，這樣就又減少了集合的元素，只有符合當前的子規(guī)則才會匹配再上一條子規(guī)則
要知道DOM樹是一個什么樣的結(jié)構(gòu)，一個元素可能有若干子元素，如果每一個都去判斷一下顯然性能太差。而一個子元素只有一個父元素，所以找起來非常方便。你可以看看css的選擇器的設(shè)計，完全是為了優(yōu)化從子元素找父元素而決定的。
所以瀏覽器解析CSS的引擎就是用這樣的算法去解析
什么是JavaScript的“預(yù)編譯”？
- 按理說，兩個簽名完全相同的函數(shù)，在其他編程語言中應(yīng)該是非法的。但在JavaScript中，這沒錯。不過，程序運行之后卻發(fā)現(xiàn)一個奇怪的現(xiàn)象：兩次調(diào)用都只是最后那個函數(shù)里輸出的值！顯然第一個函數(shù)沒有起到任何作用。這又是為什么呢？
- JavaScript執(zhí)行引擎并非一行一行地分析和執(zhí)行程序，而是一段一段地進行預(yù)編譯后讓后 再執(zhí)行的。而且，在同一段程序中，函數(shù) 在被執(zhí)行之前 會被預(yù)定義，后定定義的 同名函數(shù) 會覆蓋 先定義的函數(shù)。在調(diào)用函數(shù)的時候，只會調(diào)用后一個預(yù)定義的函數(shù)(因為后一個預(yù)定義的函數(shù)把前一個預(yù)定義的函數(shù)覆蓋了)。也就是說，在第一次調(diào)用myfunc之前，第一個函數(shù)語句定義的代碼邏輯，已被第二個函數(shù)定義語句覆蓋了。所以，兩次都調(diào)用都是執(zhí)行最后一個函數(shù)邏輯了。
一段代碼中的定義式函數(shù)語句會優(yōu)先執(zhí)行，這似乎有點象靜態(tài)語言的編譯概念。所以，這一特征也被有些人稱為：JavaScript的“預(yù)編譯”
所以總結(jié)下：JS 解析器在執(zhí)行語句前會將函數(shù)聲明和變量定義進行"預(yù)編譯"，而這個"預(yù)編譯"，并非一個頁面一個頁面地"預(yù)編譯"，而是一段一段地預(yù)編譯，所謂的段就是一 個 <script> 塊。
JavaScript是一門單線程語言，因此一旦有某個API阻塞了當前線程，就相當于阻塞了整個程序，所以“異步”在JavaScript編程中占有很重要的地位。異步編程對程序執(zhí)行效果的好處這里就不多談了，但是異步編程對于開發(fā)者來說十分麻煩，它會將程序邏輯拆分地支離破碎，語義完全丟失。因此，許多程序員都在打造一些異步編程模型已經(jīng)相關(guān)的API來簡化異步編程工作，例如Promise模型
現(xiàn)在有的異步流程控制大多是基于CommonJS Promises規(guī)范，比如 jsdeferred，jQuery自己的deferred等等
