從本篇開始會陪大家一起從零開始走一遍 jQuery 的奇妙旅途，在整個系列的實踐中，我們會把 jQuery 的主要功能子產品都了解和實作一遍。
這會是一段很長的曆程，但也會很有意思 —— 作為前端領域的經典之作，jQuery 裡有着太多奇思妙想，如果能夠深入了解它，對于我們穩固js基礎、提升前端大法技能來說大有裨益。
另外，本系列的相關代碼均可以從 我的github 上擷取到。
1. 免 new 實作
我們在使用很多插件的時候，都需要使用 new XXX() 的寫法來執行個體化一個引用:
jQuery 同樣作為一個面向對象的工具庫，在我們建立一個執行個體時卻無需使用 new 文法，節省了一些代碼量：
這種便捷的形式依賴了工廠模式，其實作非常簡單，把 new 封裝在庫内即可，讓每次調用 jQuery() 時自行在内部進行一次執行個體化：
留意這裡我們走的 IIFE 形式，讓 jQuery 代碼庫形成自己的作用域，避免污染外部變量。
于是乎以上就是咱寫的第一個 JQ 雛形，簡單跑一下：
别忘了後續我們還希望能通過 $.extend / $.fn.extend 來擴充 JQ 的靜态方法和原型方法，我們把出口方法抽出來增加這個 extend 的API：
這樣我們也能直接通過 $.fn.jquery 來擷取目前 JQ 版本号了。
如果希望可以通過 $.prototype 直接通路 jQuery 的原型對象，再修改下這句代碼即可：
2. 寫法優化
事實上我們不太喜歡再寫多一個備援的 Factory 構造函數來作為 window.jQuery 的引用，也不喜歡（在子產品内部）使用 Factory.extend() 來擴充 JQ，它聽起來和 JQ 沒有半毛錢關系。
如果可以，直接把 jQuery 方法作為接口輸出，且在子產品内部能以 jQuery.extend() 的形式來調用擴充接口，這樣的形式更佳。
也就是說我們希望代碼應該是這樣寫的：
“直接把 jQuery 方法作為接口輸出”意味着我們要把工廠模式挪入 jQuery 方法中，顯然我們不能這樣改：
這樣死循環了，調用棧會直接爆掉~
于是我們可以抽出一個 init 方法來做初始化處理（比如簡單地注入檢索到的元素到JQ對象中），把 jQuery 方法中的内容更改為 return new init(selector) 就行了。
保證兩個前提：
第一點很好了解，友善我們直接在 init 方法中通過對 this 的操作來處理 JQ 執行個體上下文，如：
針對這點，我們不妨把 init 作為 jQuery.prototype 的屬性方法來實作：
然而這時候存在一個問題 —— JQ執行個體對象無法通路原型屬性/方法：
原因很簡單——我們還未實作上述提及的第二個前提——“init 原型指向 jQuery 的原型”
在 js 中，執行個體的内部原型（__proto__）總是指向其構造函數的原型（prototype），而經過我們這番修改，JQ執行個體的構造函數已經變成了 jQuery.fn.init ，而其原型并非指向 jQuery 的原型，這導緻 JQ 執行個體無法順其原型鍊爬取到 jQuery.prototype。
要實作這個條件，隻需要做小小改動——把 jQuery.fn.init 的原型指向 jQuery 的原型（jQuery.prototype / jQuery.fn）即可：
這裡貼下完整代碼：
View Code
3. 鍊式寫法實作
JQ 裡一個很大的亮點是，它支援鍊式寫法，調用起來非常友善：
其實作其實非常簡單 —— 確定每個調用的方法尾部均傳回自身即可，這裡我們新增兩個執行個體方法做示例：
鍊式調用：
效果如下，杠杠的：
4. 沖突處理
存在某些情況，使用者可能并不想拿 window.$ 甚至 window.jQuery 來引用 JQ 接口，或者已經有其它庫使用了 window.$ 這個變量，如果我們粗暴地改變其引用肯定是不合理的。
so 我們來實作 JQ 中沖突處理的靜态接口 jQuery.noConflict，這意味着在代碼段開始時，就得先儲存下目前 window.$ 和 window.jQuery 兩個變量：
然後是實作 noConflict 方法，退耕還林，把儲存的變量吐回去即可：
deep 參數類型為 Boolean，若為真，表示要求連window.jQuery 變量都需要吐回去。
留意在尾部我們傳回了 jQuery 的接口引用，這意味着我們可以以
的形式來把它賦予新的變量。
接着在外部運作如下代碼：
輸出如下：
第一篇就寫到這裡，相關的代碼可以從 我的github 上下載下傳到。
下次我們會試着實作子產品化的寫法，并與時俱進，改用 ES6解構指派文法 + Rollup 來進行打包以減少可能存在的備援代碼段。
共勉~