一.簡述前端構(gòu)建工具。fis3，Gulp，Grunt，Webpack
www.tuicool.com/articles/beU7736
答：
（1）類是任務(wù)管理工具（task runner）。通過聲明和組合構(gòu)建任務(wù)來進(jìn)行整個(gè)網(wǎng)站的構(gòu)建， 有自己的一套任務(wù)聲明語法和任務(wù)實(shí)現(xiàn)接口。例如Grunt和Gulp，這兩個(gè)都是插件式的架構(gòu)。有大量的插件可用，缺點(diǎn)就在于做什么都只能用插件，沒有就自己寫一個(gè)。
（2）類是打包工具（package tool）。通過為每一類文件配置需要的處理方式，來實(shí)現(xiàn)整個(gè)站點(diǎn)的構(gòu)建。如Webpack和FIS，這兩個(gè)都是整個(gè)站點(diǎn)的整體構(gòu)建解決方案。fis3的使用方法見blog.csdn.net/lululove19870526/article/details/49891253
（3）類是構(gòu)建工具（build tool）。比如Make。
詳細(xì)介紹：
Webpack：Webpack 是當(dāng)下最熱門的前端資源模塊化管理和打包工具。它可以將許多松散的模塊按照依賴和規(guī)則打包成符合生產(chǎn)環(huán)境部署的前端資源。還可以將按需加載的模塊進(jìn)行代碼分隔，等到實(shí)際需要的時(shí)候再異步加載。通過 loader 的轉(zhuǎn)換，任何形式的資源都可以視作模塊，比如 CommonJs 模塊、 AMD 模塊、 ES6 模塊、CSS、圖片、 JSON、Coffeescript、 LESS 等。
webpack的優(yōu)點(diǎn)如下:
1. webpack遵循commonJS的形式,但對AMD/CMD的支持也很全面,方便舊項(xiàng)目進(jìn)行代碼遷移。
2.能被模塊化的不僅僅是JS,所有的靜態(tài)資源,例如css,圖片等都能模塊化,即以require的方式引入。
3.開發(fā)便捷,能替代部分grunt/gulp的工作,比如打包、壓縮混淆、圖片轉(zhuǎn)base64等。
Grunt：grunt是一套前端自動化工具，一個(gè)基于nodeJs的命令行工具，一般用于：壓縮文件，合并文件，簡單語法檢查。
Grunt的優(yōu)點(diǎn)如下:
Grunt生態(tài)系統(tǒng)非常龐大，并且一直在增長。由于擁有數(shù)量龐大的插件可供選擇，因此，你可以利用Grunt自動完成任何事，并且花費(fèi)最少的代價(jià)。如果找不到你所需要的插件，那就自己動手創(chuàng)造一個(gè)Grunt插件，然后將其發(fā)布到npm上吧
Gulp：基于流的自動化構(gòu)建工具。文件的壓縮打包合并,是一個(gè)純粹的工具,并不能將你的css等非js資源模塊化,通過代碼優(yōu)于配置的策略，Gulp 讓簡單的任務(wù)簡單，復(fù)雜的任務(wù)可管理。
構(gòu)建快速
利用 Node.js 流的威力，你可以快速構(gòu)建項(xiàng)目并減少頻繁的 IO 操作。
插件高質(zhì)
Gulp 嚴(yán)格的插件指南確保插件如你期望的那樣簡潔高質(zhì)得工作。
易于學(xué)習(xí)
通過最少的 API，掌握 Gulp 毫不費(fèi)力，構(gòu)建工作盡在掌握：如同一系列流管道
二.sass和less有什么區(qū)別?
答：
1.編譯環(huán)境不一樣
Sass的安裝需要Ruby環(huán)境,是在服務(wù)端處理的,而Less是需要引入less.js來處理Less代碼輸出css到瀏覽器,也可以在開發(fā)環(huán)節(jié)使用Less,然后編譯成css文件,直接放到項(xiàng)目中。
2.變量符不一相,less是@,而scss是$,而且它們的作用域也不一樣,less是塊級作用域
3.輸出設(shè)置,Less沒有輸出設(shè)置,sass供4種輸出選項(xiàng),nested,compact,compressed和expanded
nested:嵌套縮進(jìn)的css代碼(默認(rèn))
expanded:展開的多行css代碼 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? compact:簡潔格式的css代碼 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?compressed:壓縮后的css代碼
4.sass支持條件語句,可以使用if{}else{},for{}循環(huán)等等,而less不行
5.引用外部css文件,sass引用外部文件必須以_開頭,文件名如果以下劃線_形狀,sass會認(rèn)為該文件是一個(gè)引用文件,不會將其編譯為css文件。less引用外部文件和css中的@import沒什么差異。
6.sass和less的工具庫不同。sass有工具庫Compass,簡單說,sass和Compass的關(guān)系有點(diǎn)像Javascript和jQuery的關(guān)系,Compass是sass的工具庫。在它的基礎(chǔ)上,封裝了一系列有用的模塊和模板,補(bǔ)充強(qiáng)化了sass的功能。less有UI組件庫Bootstrap,Bootstrap是web前端開發(fā)中一個(gè)比較有名的前端UI組件庫,Bootstrap的樣式文件部分源碼就是采用less語法編寫。
總結(jié):不管是sass,還是less,都可以視為一種基于CSS之上的高級語言,其目的是使得CSS開發(fā)更靈活和更強(qiáng)大,sass的功能比less強(qiáng)大,基本可以說是一種真正的編程語言了,less則相對清晰明了,易于上手,對編譯環(huán)境要求比較寬松?？紤]到編譯sass要安裝Ruby,而Ruby官網(wǎng)在國內(nèi)訪問不了,個(gè)人在實(shí)際開發(fā)中更傾向于選擇less
三.sessionStorage和localstroage與cookie之間有什么關(guān)聯(lián)和區(qū)別,cookie最大存放多少字節(jié)
答：
三者共同點(diǎn):都是保存在瀏覽器端,且同源的。
1、cookie在瀏覽器和服務(wù)器間來回傳遞。而sessionStorage和localStorage不會自動把數(shù)據(jù)發(fā)給服務(wù)器,僅在本地保存
2、存儲大小限制也不同,cookie數(shù)據(jù)不能超過4k,sessionStorage和localStorage但比cookie大得多,可以達(dá)到5M
3、數(shù)據(jù)有效期不同,sessionStorage:僅在當(dāng)前瀏覽器窗口關(guān)閉前有效,自然也就不可能持久保持;localStorage:始終有效,窗口或?yàn)g覽器關(guān)閉也一直保存,因此用作持久數(shù)據(jù);cookie只在設(shè)置的cookie過期時(shí)間之前一直有效,即使窗口或?yàn)g覽器關(guān)閉
4、作用域不同,sessionStorage不在不同的瀏覽器窗口中共享,即使是同一個(gè)頁面(即數(shù)據(jù)不共享);localStorage在所有同源窗口中都是共享的;cookie也是在所有同源窗口中都是共享的(即數(shù)據(jù)共享)。
四.前端開發(fā)的優(yōu)化問題
答：
（1） 減少http請求次數(shù)：CSS Sprites, JS、CSS源碼壓縮、圖片大小控制合適；網(wǎng)頁Gzip，CDN托管，data緩存 ，圖片服務(wù)器。
（2） 前端模板 JS+數(shù)據(jù)，減少由于HTML標(biāo)簽導(dǎo)致的帶寬浪費(fèi)，前端用變量保存AJAX請求結(jié)果，每次操作本地變量，不用請求，減少請求次數(shù)
（3） 用innerHTML代替DOM操作，減少DOM操作次數(shù)，優(yōu)化javascript性能
（4） 用setTimeout來避免頁面失去響應(yīng)
（5） 用hash-table來優(yōu)化查找
（6） 當(dāng)需要設(shè)置的樣式很多時(shí)設(shè)置className而不是直接操作style
（7） 少用全局變量，緩存DOM節(jié)點(diǎn)查找的結(jié)果
（8） 緩存DOM節(jié)點(diǎn)查找的結(jié)果
（9） 避免使用CSS Expression（css表達(dá)式)又稱Dynamic properties(動態(tài)屬性)
（10） 圖片預(yù)加載，將樣式表放在頂部，將腳本放在底部加上時(shí)間戳。
（11） 避免在頁面的主體布局中使用table，table要等其中的內(nèi)容完全下載之后才會顯示出來，顯示比div+css布局慢
請說出三種減低頁面加載時(shí)間的方法
1、壓縮css、js文件
2、合并js、css文件，減少http請求
3、外部js、css文件放在最底下
4、減少dom操作，盡可能用變量替代不必要的dom操作
五.瀏覽器內(nèi)核問題和兼容問題
關(guān)于瀏覽器內(nèi)核
主要分成兩部分：渲染引擎(layout engineer或Rendering Engine)和JS引擎。
渲染引擎：負(fù)責(zé)取得網(wǎng)頁的內(nèi)容（HTML、XML、圖像等等）、整理訊息（例如加入CSS等），以及計(jì)算網(wǎng)頁的顯示方式，后會輸出至顯示器或打印機(jī)。瀏覽器的內(nèi)核的不同對于網(wǎng)頁的語法解釋會有不同，所以渲染的效果也不相同。所有網(wǎng)頁瀏覽器、電子郵件客戶端以及其它需要編輯、顯示網(wǎng)絡(luò)內(nèi)容的應(yīng)用程序都需要內(nèi)核。
JS引擎則：解析和執(zhí)行javascript來實(shí)現(xiàn)網(wǎng)頁的動態(tài)效果。
最開始渲染引擎和JS引擎并沒有區(qū)分的很明確，后來JS引擎越來越獨(dú)立，內(nèi)核就傾向于只指渲染引擎。
談?wù)劄g覽器的內(nèi)核，并且說一下什么是內(nèi)核？
Trident (['tra?d(?)nt])--IE，Gecko (['gek??])--Firefox, Presto (['prest??])--opera,webkit—谷歌和Safari
瀏覽器內(nèi)核又可以分成兩部分：渲染引擎和 JS 引擎。它負(fù)責(zé)取得網(wǎng)頁的內(nèi)容（HTML、XML、圖像等等）、整理訊息（例如加入 CSS 等），以及計(jì)算網(wǎng)頁的顯示方式，然后會輸出至顯示器或打印機(jī)。JS 引擎則是解析 Javascript 語言，執(zhí)行 javascript 語言來實(shí)現(xiàn)網(wǎng)頁的動態(tài)效果。
寫出幾種IE6 BUG的解決方法
1.雙邊距BUG float引起的 使用display
2.3像素問題 使用float引起的 使用dislpay:inline -3px
3.超鏈接hover 點(diǎn)擊后失效 使用正確的書寫順序 link visited hover active
4.Ie z-index問題 給父級添加position:relative
5.Png 透明 使用js代碼 改
6.Min-height 最小高度 ！Important 解決’
7.select 在ie6下遮蓋 使用iframe嵌套
8.為什么沒有辦法定義1px左右的寬度容器（IE6默認(rèn)的行高造成的，使用over:hidden,zoom:0.08 line-height:1px）
六.關(guān)于Ajax的面試題
ajax? 兼容性? ? 瀏覽器內(nèi)核? 請求之后的結(jié)果狀態(tài)（狀態(tài)碼）? ? 數(shù)據(jù)轉(zhuǎn)換? json數(shù)據(jù)轉(zhuǎn)換? ? 對象? 構(gòu)造函數(shù)，原型鏈，閉包? ? 緩存cooks。
1.什么是ajax：
異步j(luò)avascript和XML,是指一種創(chuàng)建交互式網(wǎng)頁應(yīng)用的網(wǎng)頁開發(fā)技術(shù)。通過后臺與服務(wù)器進(jìn)行少量數(shù)據(jù)交換,AJAX可以使網(wǎng)頁實(shí)現(xiàn)異步更新。這意味著可以在不重新加載整個(gè)網(wǎng)頁的情況下,對網(wǎng)頁的某部分進(jìn)行更新。
2.判斷AJAX瀏覽器是否支持
例子解釋：首先聲明一個(gè)保存 XMLHttpRequest 對象的 xmlHttp 變量。
然后使用 XMLHttp=new XMLHttpRequest() 來創(chuàng)建此對象。這條語句針對 Firefox、Opera 以及 Safari 瀏覽器。假如失敗，則嘗試針對 Internet Explorer 6.0+ 的 xmlHttp=new ActiveXObject("Msxml2.XMLHTTP")，假如也不成功，則嘗試針對 Internet Explorer 5.5+ 的 xmlHttp=new ActiveXObject("Microsoft.XMLHTTP")。
答：第一步，創(chuàng)建ajax對象? var xxx = new XMLHttpRequest();
第二部，判斷數(shù)據(jù)傳輸方式（GET / POST）
第三部，綁定請求地址，打開鏈接open。 即 open(method,url,async)；
第四步，發(fā)送send。即開始請求 send(string)? string：僅用于 POST 請求
第五步，獲取請求結(jié)果。
（4）xhr對象status ? readystate?readystate 0~4？說出幾個(gè)http協(xié)議狀態(tài)碼? 200 201 302 304 400 404 500？
答：
1.
status是XMLHttpRequest對象的一個(gè)屬性,表示響應(yīng)的HTTP狀態(tài)碼。readyState是XMLHttpRequest對象的一個(gè)屬性,用來標(biāo)識當(dāng)前XMLHttpRequest對象處于什么狀態(tài)。
2.
0:未初始化狀態(tài):此時(shí),已經(jīng)創(chuàng)建了一個(gè)XMLHttpRequest對象
1: 準(zhǔn)備發(fā)送狀態(tài):此時(shí),已經(jīng)調(diào)用了XMLHttpRequest對象的open方法,并且XMLHttpRequest對象已經(jīng)準(zhǔn)備好將一個(gè)請求發(fā)送到服務(wù)器端
2:已經(jīng)發(fā)送狀態(tài):此時(shí),已經(jīng)通過send方法把一個(gè)請求發(fā)送到服務(wù)器端,但是還沒有收到一個(gè)響應(yīng)
3:正在接收狀態(tài):此時(shí),已經(jīng)接收到HTTP響應(yīng)頭部信息,但是消息體部分還沒有完全接收到
4:完成響應(yīng)狀態(tài):此時(shí),已經(jīng)完成了HTTP響應(yīng)的接收
3.
200:請求成功
201:請求成功并且服務(wù)器創(chuàng)建了新的資源
302:服務(wù)器目前從不同位置的網(wǎng)頁響應(yīng)請求,但請求者應(yīng)繼續(xù)使用原有位置來響應(yīng)以后的請求。
304:自從上次請求后,請求的網(wǎng)頁未修改過。服務(wù)器返回此響應(yīng)時(shí),不會返回網(wǎng)頁內(nèi)容。
400:服務(wù)器不理解請求的語法
404:請求的資源(網(wǎng)頁等)不存在
500: 內(nèi)部服務(wù)器錯(cuò)誤
（5）如何處理ajax請求之后后臺傳過來的數(shù)據(jù)
在上面我們能看見初步獲取了 str，即獲取到后臺來的數(shù)據(jù)，有時(shí)候后臺在數(shù)據(jù)發(fā)過來之前就進(jìn)行過處理，我們 JS 獲取到就是對象，這樣就很簡單省事了。但是有時(shí)候后臺人員直接傳過來的是字符串形式，這樣就需要我們苦逼的前端去處理一下數(shù)據(jù)了。然后問題就來了我們該怎么去處理字符串，哪種處理方式更好；
目前js處理有兩種：1、eval()。2、JSON.parse()；那么這兩種有什么區(qū)別呢？
注意：eval()的功能是把對應(yīng)的字符串解析成JS代碼并運(yùn)行；應(yīng)該避免使用eval，不安全，非常耗性能（2個(gè)步驟，一次解析成js語句，一次執(zhí)行）
（6）ajax緩存原理
ajax的缺點(diǎn)
1、ajax不支持瀏覽器back按鈕。
2、安全問題AJAX暴露了與服務(wù)器交互的細(xì)節(jié)。
3、對搜索引擎的支持比較弱。
4、破壞了程序的異常機(jī)制。
（7）ajax請求方式有幾種
如果你指定了 dataType 選項(xiàng)，請確保服務(wù)器返回正確的 MIME 信息，(如 xml 返回"text/xml")。
實(shí)例：
保存數(shù)據(jù)到服務(wù)器，成功時(shí)顯示信息。
$.ajax({
type:"post",
dataType:"html",
url:'/Resources/GetList.ashx',
data: dataurl,
success: function (data) {if(data !="") {
$("#pager").pager({ pagenumber: pagenumber, pagecount: data.split("$")[1], buttonClickCallback: PageClick });
$("#anhtml").html(data.split("$")[0]);
}
}
});
（8）ajax和jsonp
答：
相同點(diǎn):都是請求一個(gè)url
不同點(diǎn):ajax的核心是通過xmlHttpRequest獲取內(nèi)容
jsonp的核心則是動態(tài)添加<script>標(biāo)簽來調(diào)用服務(wù)器，提供的js腳本標(biāo)簽來調(diào)用服務(wù)器 供的js腳本。
標(biāo)簽來調(diào)用服務(wù)器提供的js腳本標(biāo)簽來調(diào)用服務(wù)器提供的js腳本標(biāo)簽來調(diào)用服務(wù)器提供的js腳本。
標(biāo)簽來調(diào)用服務(wù)器? 供的js腳本。
（9）關(guān)于跨域問題
blog.csdn.net/joyhen/article/details/21631833
答：(1)jsonp是用script標(biāo)簽的src屬性是不跨域的這一性質(zhì)，所以其實(shí)是封裝了這個(gè)功能而已，jquery會創(chuàng)建一個(gè)script標(biāo)簽，把src的地址指向后端，src會帶一個(gè)callback參數(shù)，一般是一個(gè)函數(shù)名，后端根據(jù)這個(gè)請求，獲取參數(shù)，然后把需要返回的數(shù)據(jù)包裹在這個(gè)函數(shù)內(nèi)，前端獲得了這些js代碼，就會執(zhí)行這個(gè)callback，自然就把數(shù)據(jù)傳到客戶端了。只支持GET請求參考文檔
(2)cors(cross-origin resource sharing)就是服務(wù)端加上一句 header(“Access-Control-Allow-Origin:*”); 支持所有請求，但是兼容性不太好，支持IE8+,chrome3+。 (3)window.name.一個(gè)窗口window的生命周期內(nèi)，窗口載入的頁面共享一個(gè)window.name,每個(gè)頁面都有讀寫權(quán)限, data.html里面就寫上window.name=”data..”;然后在a.html里用一個(gè)隱藏的iframe載入data.html,然后在a.html里用js把iframe的src設(shè)為同源的一個(gè)頁面。
(4)修改document.domain的方法只適用于不同子域的框架間的交互。比如http://www.example.com/a.html和 http:example.com/b.html 在兩個(gè)頁面中都修改document.domain為”example.com”
(5)img標(biāo)簽的src也是不跨域的，所以可以
img.src=“http://example.com/data?value=123。
但是這種方法只能用來發(fā)送請求.
(6)HTML5有一個(gè)postMessage(data,origin)方法，可以向當(dāng)前頁面中的iframe或者當(dāng)前頁彈出的窗口發(fā)送消息
1，jsonp
2，PHP端修改header ? 利用CORS
3，代理：
例如www.123.com/index.html需要調(diào)用www.456.com/server.php，可以寫一個(gè)接口www.123.com/server.php，由這個(gè)接口在后端去調(diào)用www.456.com/server.php并拿到返回值，然后再返回給index.html，這就是一個(gè)代理的模式。相當(dāng)于繞過了瀏覽器端，自然就不存在跨域問題。
4，document.domain + iframe? ? ? (只有在主域相同的時(shí)候才能使用該方法)
問題：
1、安全性，當(dāng)一個(gè)站點(diǎn)被攻擊后，另一個(gè)站點(diǎn)會引起安全漏洞。
2、如果一個(gè)頁面中引入多個(gè)iframe，要想能夠操作所有iframe，必須都得設(shè)置相同domain。
5.window.name + iframe
window.name 的美妙之處：name 值在不同的頁面（甚至不同域名）加載后依舊存在，并且可以支持非常長的 name 值（2MB）。
1) 創(chuàng)建a.com/cs1.html
2) 創(chuàng)建a.com/proxy.html，并加入如下代碼
6.web sockets
七.關(guān)于HTTP的問題總結(jié)? ：（http://www.360doc.com/content/10/0930/17/3668821_57590979.shtml）
（osi七種模型介紹 https://www.zybang.com/question/f05fd53d632bfa9dd5fef66552234c84.html?ssl=1）
一個(gè)頁面從輸入U(xiǎn)RL到頁面加載顯示完成，這個(gè)過程中都發(fā)生了什么？
這個(gè)過程可以分為四個(gè)步驟：
1.當(dāng)發(fā)送一個(gè)URL請求時(shí)，不管這個(gè)URL是web頁面的URL還是web頁面的每個(gè)資源的URL，瀏覽器都會開啟一個(gè)線程來處理這個(gè)請求，同時(shí)在遠(yuǎn)程DNS服務(wù)器上啟動一個(gè)DNS查詢，這樣就可以使得瀏覽器獲得請求對應(yīng)的IP地址了。
2.瀏覽器通過與遠(yuǎn)程web服務(wù)器TCP三次握手協(xié)商來建立一個(gè)TCP/IP鏈接。三個(gè)握手包含一個(gè)同步報(bào)文，一個(gè)同步-應(yīng)答報(bào)文和一個(gè)應(yīng)答報(bào)文，這三個(gè)報(bào)文在瀏覽器和服務(wù)器之間進(jìn)行傳遞，該握手首先由客戶端嘗試建立起通信，而后服務(wù)器應(yīng)答并接受客戶端的請求，最后由由客戶端發(fā)出該請求已經(jīng)被接受的報(bào)文。
3.一旦TCP/IP鏈接建立，瀏覽器會通過該鏈接向遠(yuǎn)程服務(wù)器發(fā)送HTTP的GET請求。遠(yuǎn)程服務(wù)器找到資源并使用HTTP響應(yīng)返回該資源，值為200的HTTP狀態(tài)碼表示一個(gè)正確的響應(yīng)。
4.此時(shí)，web服務(wù)器提供資源服務(wù)，客戶端開始下載資源。
簡單來說，瀏覽器會解析HTML生成DOM tree，其次會根據(jù)CSS生成CSS rule tree,而javascript又可以根據(jù)DOM api操作DOM
在這里再歸納下http狀態(tài)嗎有哪些？它們分別代表什么意思？
要熟悉前后端的通信流程，最好把動態(tài)網(wǎng)站的背后細(xì)節(jié)也介紹一遍
八.AMD,CMD，CommonJS以及RequireJS和SeaJS的個(gè)人感悟
AMD 是 RequireJS 在推廣過程中對模塊定義的規(guī)范化產(chǎn)出。
CMD 是 SeaJS 在推廣過程中對模塊定義的規(guī)范化產(chǎn)出。
類似的還有 CommonJS Modules/2.0 規(guī)范，是 BravoJS 在推廣過程中對模塊定義的規(guī)范化產(chǎn)出。
這些規(guī)范的目的都是為了 JavaScript 的模塊化開發(fā)，特別是在瀏覽器端的。
目前這些規(guī)范的實(shí)現(xiàn)都能達(dá)成瀏覽器端模塊化開發(fā)的目的。
AMD與CDM的區(qū)別：
1.對于于依賴的模塊，AMD 是提前執(zhí)行(好像現(xiàn)在也可以延遲執(zhí)行了)，CMD 是延遲執(zhí)行。
2.AMD 推崇依賴前置，CMD 推崇依賴就近。
3.AMD 推崇復(fù)用接口，CMD 推崇單用接口。
4.書寫規(guī)范的差異，不具體說明了。
1. 對于依賴的模塊，AMD 是提前執(zhí)行，CMD 是延遲執(zhí)行。
不過 RequireJS 從 2.0 開始，也改成可以延遲執(zhí)行（根據(jù)寫法不同，處理方式不同）。CMD 推崇 as lazy as possible.
2. CMD 推崇依賴就近，AMD 推崇依賴前置?？创a：
// CMD
define(function(require, exports, module) {
var a = require('./a')
a.doSomething()
// 此處略去 100 行
var b = require('./b') // 依賴可以就近書寫
b.doSomething()
// ...
})
// AMD 默認(rèn)推薦的是
define(['./a', './b'], function(a, b) { // 依賴必須一開始就寫好
a.doSomething()
// 此處略去 100 行
b.doSomething()
...
})
雖然 AMD 也支持 CMD 的寫法，同時(shí)還支持將 require 作為依賴項(xiàng)傳遞，但 RequireJS 的作者默認(rèn)是最喜歡上面的寫法，也是官方文檔里默認(rèn)的模塊定義寫法。
3. AMD 的 API 默認(rèn)是一個(gè)當(dāng)多個(gè)用，CMD 的 API 嚴(yán)格區(qū)分，推崇職責(zé)單一。比如 AMD 里，require 分全局 require 和局部 require，都叫 require。CMD 里，沒有全局 require，而是根據(jù)模塊系統(tǒng)的完備性，提供 seajs.use 來實(shí)現(xiàn)模塊系統(tǒng)的加載啟動。CMD 里，每個(gè) API 都簡單純粹。
4. 還有一些細(xì)節(jié)差異，具體看這個(gè)規(guī)范的定義就好，就不多說了。
另外，SeaJS 和 RequireJS 的差異，可以參考
執(zhí)行模塊的機(jī)制大不一樣
-----------------------------------
由于 RequireJS 是執(zhí)行的 AMD 規(guī)范, 因此所有的依賴模塊都是先執(zhí)行.
使用 RequireJS 默認(rèn)定義模塊的方式, 在理解上會更清楚一些, 但個(gè)人還是偏愛 require('./mod1') 這樣的方式
define(['dep1', 'dep2'], function (dep1, dep2) {
//Define the module value by returning a value.
return function () {};
});
SeaJS 和 RequireJS 的差異
SeaJS只會在真正需要使用(依賴)模塊時(shí)才執(zhí)行該模塊
SeaJS是異步加載模塊的沒錯(cuò), 但執(zhí)行模塊的順序也是嚴(yán)格按照模塊在代碼中出現(xiàn)(require)的順序
而RequireJS會先盡早地執(zhí)行(依賴)模塊, 相當(dāng)于所有的require都被提前了, 而且模塊執(zhí)行的順序也不一定100%就是先mod1再mod2
因此你看到執(zhí)行順序和你預(yù)想的完全不一樣! 顫抖吧~ RequireJS!
CommonJS:就是用來規(guī)范JS的使用的，主要為了JS在后端的表現(xiàn)制定的，不太適合前端。它定了三個(gè)模塊：模塊引用的require，模塊定義的exports和模塊標(biāo)識module。CommonJS是一種規(guī)范，包括很多內(nèi)容，NodeJS是這種規(guī)范的實(shí)現(xiàn)。
RequireJS與SeaJS 都是模塊加載器。RequireJS工作于web瀏覽器端，同時(shí)也工作于web服務(wù)器端，SeaJS專注于web瀏覽器端。
網(wǎng)站：1?www.cnblogs.com/jackyWHJ/articles/4943271.html
入門requirejs ? http://www.runoob.com/w3cnote/requirejs-tutorial-2.html
異步加載的方式有哪些？
方案一：標(biāo)簽的async="async"屬性（詳細(xì)參見：script標(biāo)簽的async屬性）
方案二：標(biāo)簽的defer="defer"屬性標(biāo)簽的defer="defer"屬性方案三：動態(tài)創(chuàng)建標(biāo)簽方案四：AJAX eval（使用AJAX得到腳本內(nèi)容，然后通過eval_r(xmlhttp.responseText)來運(yùn)行腳本）方案五：iframe方式
方案三：動態(tài)創(chuàng)建標(biāo)簽
方案四：AJAX eval（使用AJAX得到腳本內(nèi)容，然后通過eval_r(xmlhttp.responseText)來運(yùn)行腳本）
方案五：iframe方式
類型九：對于線程·和進(jìn)程的理解
操作系統(tǒng)的設(shè)計(jì)，因此可以歸結(jié)為三點(diǎn)：
（1）以多進(jìn)程形式，允許多個(gè)任務(wù)同時(shí)運(yùn)行；
（2）以多線程形式，允許單個(gè)任務(wù)分成不同的部分運(yùn)行；
（3）提供協(xié)調(diào)機(jī)制，一方面防止進(jìn)程之間和線程之間產(chǎn)生沖突，另一方面允許進(jìn)程之間和線程之間共享資源。
3.區(qū)別
進(jìn)程和線程的主要差別在于它們是不同的操作系統(tǒng)資源管理方式。進(jìn)程有獨(dú)立的地址空間，一個(gè)進(jìn)程崩潰后，在保護(hù)模式下不會對其它進(jìn)程產(chǎn)生影響，而線程只是一個(gè)進(jìn)程中的不同執(zhí)行路徑。線程有自己的堆棧和局部變量，但線程之間沒有單獨(dú)的地址空間，一個(gè)線程死掉就等于整個(gè)進(jìn)程死掉，所以多進(jìn)程的程序要比多線程的程序健壯，但在進(jìn)程切換時(shí)，耗費(fèi)資源較大，效率要差一些。但對于一些要求同時(shí)進(jìn)行并且又要共享某些變量的并發(fā)操作，只能用線程，不能用進(jìn)程。
1)?簡而言之,一個(gè)程序至少有一個(gè)進(jìn)程,一個(gè)進(jìn)程至少有一個(gè)線程.
2)?線程的劃分尺度小于進(jìn)程，使得多線程程序的并發(fā)性高。
3)?另外，進(jìn)程在執(zhí)行過程中擁有獨(dú)立的內(nèi)存單元，而多個(gè)線程共享內(nèi)存，從而極大地提高了程序的運(yùn)行效率。
4)線程在執(zhí)行過程中與進(jìn)程還是有區(qū)別的。每個(gè)獨(dú)立的線程有一個(gè)程序運(yùn)行的入口、順序執(zhí)行序列和程序的出口。但是線程不能夠獨(dú)立執(zhí)行，必須依存在應(yīng)用程序中，由應(yīng)用程序提供多個(gè)線程執(zhí)行控制。
5)從邏輯角度來看，多線程的意義在于一個(gè)應(yīng)用程序中，有多個(gè)執(zhí)行部分可以同時(shí)執(zhí)行。但操作系統(tǒng)并沒有將多個(gè)線程看做多個(gè)獨(dú)立的應(yīng)用，來實(shí)現(xiàn)進(jìn)程的調(diào)度和管理以及資源分配。這就是進(jìn)程和線程的重要區(qū)別。
4.優(yōu)缺點(diǎn)
線程和進(jìn)程在使用上各有優(yōu)缺點(diǎn)：線程執(zhí)行開銷小，但不利于資源的管理和保護(hù)；而進(jìn)程正相反。同時(shí)，線程適合于在SMP機(jī)器上運(yùn)行，而進(jìn)程則可以跨機(jī)器遷移。
類型十：關(guān)于Jquery
1.jquery 中如何將數(shù)組轉(zhuǎn)化為json字符串，然后再轉(zhuǎn)化回來？
jQuery中沒有提供這個(gè)功能，所以你需要先編寫兩個(gè)jQuery的擴(kuò)展：
$.fn.stringifyArray = function(array) {
return JSON.stringify(array)
}
$.fn.parseArray = function(array) {
return JSON.parse(array)
}
然后調(diào)用：
$("").stringifyArray(array)
2.jQuery中.bind() .live() .delegate() .on()的區(qū)別
類型十一：關(guān)于js
1.說說你對this的理解？
在JavaScript中，this通常指向的是我們正在執(zhí)行的函數(shù)本身，或者是，指向該函數(shù)所屬的對象。
全局的this → 指向的是Window
函數(shù)中的this → 指向的是函數(shù)所在的對象
對象中的this → 指向其本身
2.繼承的幾種方式 ?www.cnblogs.com/humin/p/4556820.html
1.原型鏈繼承
2.借用構(gòu)造函數(shù)繼承
3.組合繼承(原型+借用構(gòu)造)
4.原型式繼承
5.寄生式繼承
6.寄生組合式繼承
構(gòu)造函數(shù).prototype= 原型對象
原型對象.constructor = 構(gòu)造函數(shù)(模板)
原型對象.isPrototypeof(實(shí)例對象)? 判斷實(shí)例對象的原型 是不是當(dāng)前對象
3.關(guān)于事件
（1）關(guān)于事件，IE與火狐的事件機(jī)制有什么區(qū)別？ 如何阻止冒泡？
[1].在IE中,事件對象是作為一個(gè)全局變量來保存和維護(hù)的.所有的瀏覽器事件,不管是用戶觸發(fā)的，還是其他事件,都會更新window.event對象.所以在代碼中，只要調(diào)用window.event就可以獲取事件對象， 再event.srcElement就可以取得觸發(fā)事件的元素進(jìn)行進(jìn)一步處理.
[2].在FireFox中，事件對象卻不是全局對象，一般情況下，是現(xiàn)場發(fā)生，現(xiàn)場使用，F(xiàn)ireFox把事件對象自動傳給事件處理程序.
關(guān)于事件的兼容性處理要熟練掌握，事件對象具體哪些屬性存在兼容性問題，IE與標(biāo)準(zhǔn)事件模型事件冒泡與事件捕獲的支持要理解
（2）如何阻止事件冒泡和默認(rèn)事件？
阻止瀏覽器的默認(rèn)行為
window.event?window.event.returnValue=false:e.preventDefault();
停止事件冒泡
window.event?window.event.cancelBubble=true:e.stopPropagation();
原生JavaScript中，return false;只阻止默認(rèn)行為，不阻止冒泡，jQuery中的return false;既阻止默認(rèn)行為，又阻止冒泡
4.關(guān)于window對象（event，navigator，history，location）
關(guān)于history（通過history.pushState無刷新改變url）
http://www.myexception.cn/web/1955044.html
在瀏覽器中改變地址欄url，將會觸發(fā)頁面資源的重新加載，這使得我們可以在不同的頁面間進(jìn)行跳轉(zhuǎn)，得以瀏覽不同的內(nèi)容。但隨著單頁應(yīng)用的增多，越來越多的網(wǎng)站采用ajax來加載資源。因?yàn)楫惒郊虞d的特性，地址欄上的資源路徑?jīng)]有被改變，隨之而來的問題就是頁面的狀態(tài)無法被保存。這導(dǎo)致我們難以通過熟悉的方式（點(diǎn)擊瀏覽器前進(jìn)/后退按鈕），在前后的頁面狀態(tài)間進(jìn)行切換。
為了解決ajax頁面狀態(tài)不能返回的問題，人們想出了一些曲線救國的方法，比如利用瀏覽器hash的特性，將新的資源路徑偽裝成錨點(diǎn)，通過onhashchange事件來改變狀態(tài)，同時(shí)又避免了瀏覽器刷新。但這樣始終顯得有些hack。
現(xiàn)在HTML5規(guī)范為window.history引入了兩個(gè)新api，pushState和replaceState，我們可以使用它很方便的達(dá)到改變url不重載頁面的目的
#hash最后再來介紹另一種無刷新技巧window.location.hash的使用。
URL中#稱為位置的標(biāo)識符，代表網(wǎng)頁中的一個(gè)位置，當(dāng)瀏覽器讀取這個(gè)URL后，會自動將可視區(qū)域滾動至所定義的錨點(diǎn)處。HTTP請求中不包括#，也就是說改變#后的內(nèi)容不會向服務(wù)器發(fā)起請求，因此也就不會引起頁面重載。
window.location.hash這個(gè)屬性可讀可寫。讀取時(shí)，可以用來判斷網(wǎng)頁狀態(tài)是否改變；寫入時(shí)，則會在不重載網(wǎng)頁的前提下，創(chuàng)造一條訪問歷史記錄。
當(dāng)#值發(fā)生變化時(shí)，就會觸發(fā)onhashchange事件。
