前端面試題（綜合部分）

webpack：
1、對webpack的理解
1.WebPack 是一個模塊打包工具，你可使用WebPack管理你的模塊依賴，並編繹輸出模塊們所需的靜態文件。它可以很好地管理、打包Web開發中所用到的HTML、JavaScript、CSS以及各類靜態文件（圖片、字體等），讓開發過程更加高效。對於不一樣類型的資源，webpack有對應的模塊加載器。webpack模塊打包器會分析模塊間的依賴關係，最後 生成了優化且合併後的靜態資源。
2.webpack的兩大特點：代碼分割和模塊處理
2、熱重啓
1.熱重啓原理：eventsource sse，一旦服務器資源有更新，可以及時通知到客戶端，從而實時的反饋到用戶界面上。本質上是一個http，經過response流實時推送服務器信息到客戶端。連接斷開後會持續出發重連。_webpack_hmr:每隔10s推送一條在消息到瀏覽器
2.實現：
client：建立new EventSource （「／message」），
Server：須要返回類型爲text／event-stream的響應頭，發送數據以data開頭，\n\n結尾；
webpack-dev-server是一個機遇express的web server，監聽8080，server內部調用webpack，這樣的好處是提供了熱加載和熱替換的功能；
webpack-hot-middleware和webpack-dev-middleware
3.EventSource和websocket的區別：
（1）.eventSource本質仍然是http，僅提供服務器端到瀏覽器端的單向文本傳輸，不須要心跳連接，連接斷開回持續重發連接；
（2）.websocket是基於TCP的協議，提供雙向數據傳輸，支持二進制，須要心跳連接，斷開連接不會重鏈；
（3）.EventSource更簡潔輕量，WebSocket支持行更好（IE10+）。後者功能更強大一點。
3、webpack特性
全部的資源均可以看成一個模塊來處理，熱替換（不用刷新整個頁面），代碼拆分和按需加載，擁有靈活的可擴展plugin庫和loader模塊加載器；
4、如何使用經常使用插件？
1.HtmlWebpackPlugin的用法及多入口文件配置：做用是依據一個html模版，生成html文件，並將打包後的資源文件自動引入（title：；template：’‘，fileName：‘’，inject：js插入位置等）；
2.webpack.optimize.commonsChunkPlugin:抽取公共模塊,減少打包體積，例如：vue的源碼、jquery的源碼等：entry：vendor：[‘react’];plugin:new web pack.optimize.CommonsChunkPlugin({name:’vendor’})
3.loader：
css：解析css代碼，在js中經過require方式引入css文件
style：經過style的方式引入 {test:/\.css$/,loader:’style-loader!css-loader’}，兩者組合能將css代碼寫入到js文件中

4.將樣式抽取成單獨的文件，extract-text-webpack-plugin（filename：‘’）：
5.url-loader：實現圖片文字等的打包，有一個option選項limit屬性表示，少於這個限制，則打包成base64，大於的話，就使用file-loader去打包成圖片；
6.postcss：實現瀏覽器兼容，autoprefixer
7.babel：轉es
8.hot module replacement：修改代碼後，自動刷新實時預覽修改後的效果。devServer：{hot:true,inline:true(實時刷新)}
9.ugliifyJsPlugin：壓縮js代碼
5、webpack與gulp的比較
1.gulp是工具鏈，能夠配合各類插件作js、css壓縮，less編譯等；而webpack能把項目中的各類js、css文件等打包合併成一個或者多個文件，主要用於模塊化方案，
2.側重點不一樣，gulp側重於整個過程的控制管理（像是流水線），經過配置不一樣的task，構建整個前端開發流程；webpack則側重於模塊打包；而且gulp的打包功能是經過安裝gulp-webpack來實現的
3.webpack可以按照模塊的依賴關係構建文件組織結構；
6、webpack多頁面打包

web-webpack-plugin裏的AutoWebPlugin能夠方便的解決這些問題。
module.exports = {
plugins: [
// 全部頁面的入口目錄
new AutoWebPlugin('./src/'),
]
};
AutoWebPlugin會把./src/目錄下全部每一個文件夾做爲一個單頁頁面的入口，自動爲全部的頁面入口配置一個WebPlugin輸出對應的html。要新增一個頁面就在./src/下新建一個文件夾包含這個單頁應用所依賴的代碼，AutoWebPlugin自動生成一個名叫文件夾名稱的html文件。

7、webpack打包原理
核心思想：
一切皆模塊：
正如js文件能夠是一個「模塊（module）」同樣，其餘的（如css、image或html）文件也可視做模 塊。所以，你能夠require(‘myJSfile.js’)亦能夠require(‘myCSSfile.css’)。這意味着咱們能夠將事物（業務）分割成更小的易於管理的片斷，從而達到重複利用等的目的。
按需加載：
傳統的模塊打包工具（module bundlers）最終將全部的模塊編譯生成一個龐大的bundle.js文件。可是在真實的app裏邊，「bundle.js」文件可能有10M到15M之大可能會致使應用一直處於加載中狀態。所以Webpack使用許多特性來分割代碼而後生成多個「bundle」文件，並且異步加載部分代碼以實現按需加載。

文件管理
每一個文件都是一個資源，能夠用require/import導入js
每一個入口文件會把本身所依賴(即require)的資源所有打包在一塊兒，一個資源屢次引用的話，只會打包一份
對於多個入口的狀況，其實就是分別獨立的執行單個入口狀況，每一個入口文件不相干(可用CommonsChunkPlugin優化)

打包原理
把全部依賴打包成一個bundle.js文件，經過代碼分割成單元片斷並按需加載。

如圖，entry.js是入口文件，調用了util1.js和util2.js，而util1.js又調用了util2.js。

打包後的bundle.js例子

/******/ ([
/* 0 */     //模塊id
/***/ function(module, exports, __webpack_require__) {

    __webpack_require__(1);     //require資源文件id
    __webpack_require__(2);

/***/ },
/* 1 */
/***/ function(module, exports, __webpack_require__) {
    //util1.js文件
    __webpack_require__(2);
    var util1=1;
    exports.util1=util1;

/***/ },
/* 2 */
/***/ function(module, exports) {
    //util2.js文件
    var util2=1;
    exports.util2=util2;

/***/ }
...
...
/******/ ]);

一、bundle.js是以模塊 id 爲記號，經過函數把各個文件依賴封裝達到分割效果，如上代碼 id 爲 0 表示 entry 模塊須要的依賴， 1 表示 util1模塊須要的依賴
二、require資源文件 id 表示該文件須要加載的各個模塊，如上代碼_webpack_require__(1) 表示 util1.js 模塊，__webpack_require__(2) 表示 util2.js 模塊
三、exports.util1=util1 模塊化的體現，輸出該模塊

8、webpack構建流程
從啓動webpack構建到輸出結果經歷了一系列過程，它們是：
一、解析webpack配置參數，合併從shell傳入和webpack.config.js文件裏配置的參數，生產最後的配置結果。
二、註冊全部配置的插件，好讓插件監聽webpack構建生命週期的事件節點，以作出對應的反應。
三、從配置的entry入口文件開始解析文件構建AST語法樹，找出每一個文件所依賴的文件，遞歸下去。
四、在解析文件遞歸的過程當中根據文件類型和loader配置找出合適的loader用來對文件進行轉換。
五、遞歸完後獲得每一個文件的最終結果，根據entry配置生成代碼塊chunk。
六、輸出全部chunk到文件系統。
須要注意的是，在構建生命週期中有一系列插件在合適的時機作了合適的事情，好比UglifyJsPlugin會在loader轉換遞歸完後對結果再使用UglifyJs壓縮覆蓋以前的結果。
9、webpack構建優化
方案1、合理配置 CommonsChunkPlugin
webpack的資源入口一般是以entry爲單元進行編譯提取，那麼當多entry共存的時候，CommonsChunkPlugin的做用就會發揮出來，對全部依賴的chunk進行公共部分的提取，可是在這裏可能不少人會誤認爲抽取公共部分指的是能抽取某個代碼片斷，其實並不是如此，它是以module爲單位進行提取。
方案2、經過 externals 配置來提取經常使用庫
簡單來講external就是把咱們的依賴資源聲明爲一個外部依賴，而後經過script外鏈腳本引入。這也是咱們早期頁面開發中資源引入的一種翻版，只是經過配置後能夠告知webapck遇到此類變量名時就能夠不用解析和編譯至模塊的內部文件中，而改用從外部變量中讀取，這樣能極大的提高編譯速度，同時也能更好的利用CDN來實現緩存。
方案3、利用 DllPlugin 和 DllReferencePlugin 預編譯資源模塊
咱們的項目依賴中一般會引用大量的npm包，而這些包在正常的開發過程當中並不會進行修改，可是在每一次構建過程當中卻須要反覆的將其解析，如何來規避此類損耗呢？這兩個插件就是幹這個用的。
簡單來講DllPlugin的做用是預先編譯一些模塊，而DllReferencePlugin則是把這些預先編譯好的模塊引用起來。這邊須要注意的是DllPlugin必需要在DllReferencePlugin執行前先執行一次，dll這個概念應該也是借鑑了windows程序開發中的dll文件的設計理念。
方案4、使用 Happypack 加速你的代碼構建
以上介紹均爲針對webpack中的chunk計算和編譯內容的優化與改進，對資源的實際體積改進上也較爲明顯，那麼除此以外，咱們可否針對資源的編譯過程和速度優化上作些嘗試呢？
衆所周知，webpack中爲了方便各類資源和類型的加載，設計了以loader加載器的形式讀取資源，可是受限於node的編程模型影響，全部的loader雖然以async的形式來併發調用，可是仍是運行在單個 node的進程以及在同一個事件循環中，這就直接致使了當咱們須要同時讀取多個loader文件資源時，好比babel-loader須要transform各類jsx，es6的資源文件。在這種同步計算同時須要大量耗費cpu運算的過程當中，node的單進程模型就無優點了，那麼happypack就針對解決此類問題而生。
方案5、加強 uglifyPlugin
uglifyJS憑藉基於node開發，壓縮比例高，使用方便等諸多優勢已經成爲了js壓縮工具中的首選，可是咱們在webpack的構建中觀察發現，當webpack build進度走到80%先後時，會發生很長一段時間的停滯，經測試對比發現這一過程正是uglfiyJS在對咱們的output中的bunlde部分進行壓縮耗時過長致使，針對這塊咱們推薦使用webpack-uglify-parallel來提高壓縮速度。
10、談談你對預加載的理解？
Web預加載指的是在網頁全加載完成以前，在頁面優先顯示一些主要內容，以提升用戶體驗。對於一個較龐大的網站，若是沒有使用預加載技術，用戶界面就會長時間顯示一片空白，直到資源加載完成，頁面纔會顯示內容。
例如，能夠經過js預先從服務加載圖片資源(動態建立Image，設置src屬性)，只要瀏覽器把圖片下載到本地，就會被緩存，再次請求至關的src時就會優先尋找瀏覽器緩存，提升訪問速度。
11、緩存和預加載的區別是什麼？
緩存就是把請求過的數據緩存起來，下次請求的時候直接使用緩存內容，提升響應速度
預加載指的是提早把須要的內容加載完成，訪問的時候能夠明天提升響應效率，好比圖片的預加載（能夠提早加載必定數量的圖片，當用戶訪問圖片的時候通常只看前幾張，因爲是預加載好的，因此速度比較快）
12、CDN是啥？
CDN的全稱：是Content DeliveryNetwork，即內容分發網絡，加速的意思，那麼網站CND服務就是網站加速服務。
CDN加速原理：CDN加速將網站的內容緩存在網絡邊緣（離用戶接入網絡最近的地方），而後在用戶訪問網站內容的時候，經過調度系統將用戶的請求路由或者引導到離用戶接入網絡最近或者訪問效果最佳的緩存服務器上，有該緩存服務器爲用戶提供內容服務；相對於直接訪問源站，這種方式縮短了用戶和內容之間的網絡距離，從而達到加速的效果。
CDN的特色：
一、本地加速 提升了企業站點(尤爲含有大量圖片和靜態頁面站點)的訪問速度，並大大提升以上性質站點的穩定性
二、鏡像服務 消除了不一樣運營商之間互聯的瓶頸形成的影響，實現了跨運營商的網絡加速，保證不一樣網絡中的用戶都能獲得良好的訪問質量。
三、遠程加速 遠程訪問用戶根據DNS負載均衡技術 智能自動選擇Cache服務器，選擇最快的Cache服務器，加快遠程訪問的速度
四、帶寬優化 自動生成服務器的遠程Mirror(鏡像)cache服務器，遠程用戶訪問時從cache服務器上讀取數據，減小遠程訪問的帶寬、分擔網絡流量、減輕原站點WEB服務器負載等功能。
五、集羣抗攻擊 普遍分佈的CDN節點加上節點之間的智能冗於機制，能夠有效地預防黑客入侵以及下降各類D.D.o.S攻擊對網站的影響，同時保證較好的服務質量。
十3、ajax請求的時候get 和post方式的區別?
1. GET請求會將參數跟在URL後進行傳遞，而POST請求則是做爲HTTP消息的實體內容發送給WEB服務器。固然在Ajax請求中，這種區別對用戶是不可見的
二、GEt傳輸數據容量小，不安全，post傳輸數據內容大，更加安全；
十4、AJAX的工做原理
Ajax的工做原理至關於在用戶和服務器之間加了—箇中間層(AJAX引擎),使用戶操做與服務器響應異步化。並非全部的用戶請求都提交給服務器,像—些數據驗證和數據處理等都交給Ajax引擎本身來作, 只有肯定須要從服務器讀取新數據時再由Ajax引擎代爲向服務器提交請求。
十5、建立ajax過程
(1)建立XMLHttpRequest對象,也就是建立一個異步調用對象.
(2)建立一個新的HTTP請求,並指定該HTTP請求的方法、URL及驗證信息.
(3)設置響應HTTP請求狀態變化的函數.
(4)發送HTTP請求.
(5)獲取異步調用返回的數據.
(6)使用JavaScript和DOM實現局部刷新.
十6、從地址欄輸入URL到頁面加載完成發生了什麼？
1.域名解析,首先瀏覽器會解析域名爲對應的IP地址(解析的過程是依次瀏覽器搜索自身DNS緩存->瀏覽器搜索操做系統DNS緩存->讀取hosts文件->瀏覽器向DNS服務器發送請求,其中任何一個環節解析成功,解析就會終止);
2.發起TCP的3次握手(握手過程當中傳送的包裏不包含數據，三次握手完畢後，客戶端與服務器才正式開始傳送數據)；
3.創建TCP鏈接後發起http請求(經常使用get/post)；
4.服務器響應請求,返回數據,瀏覽器獲得html代碼；
5.瀏覽器解析html代碼,並請求html代碼中的資源；
6.瀏覽器對頁面進行渲染呈現給用戶。
總結：
域名解析—> 發起TCP3次握手 —>創建TCP連接後發起Http請求 —>服務器響應Http請求，瀏覽器獲得html代碼 —> 瀏覽器解析Html代碼，並請求Html代碼中的資源(如：圖片，js，css等) —> 瀏覽器對頁面進行渲染呈現給用戶。