一，常見的模塊化構建工具 webpack
答：Gulp、Grunt、Webpack
1,Grunt和Gulp都是前端自動化構建工具，可以進行文件的合併壓縮，但是gulp比grunt更高效，因爲它可以支持異步多任務，更易於使用，插件也有更高的質量
2.Webpack是前端資源模塊化管理和打包工具，是一個模塊打包器，在他的視野裏，前端所有的資源文件都會作爲模塊處理它將根據模塊的依賴關係，生成對應的靜態資源
3.webpack的工作方式是:將項目看成一個整體，通過一個給定的主文件，比如index.js，Webpack將從這個文件開始找到項目裏的所有依賴文件，使用loaders處理他們，最後打包爲一個(或多個)瀏覽器可識別的Javascript文件
4.與gulp和grunt相比，Webpack處理速度更快，能打包不同類型的文件，更重要的是，webpack是一個模塊化打包工具,gulp和grunt也高度依賴插件
二，Webpack的四個核心概念：入口(entry),輸出(output)、loader、插件(plugin)
(1)入口(entry):指示webpack應該使用哪個模塊，來作爲構建其內部依賴圖的開始，進入起點入口以後，webpack會找出哪些模塊和庫是入口起點(直接和間接)依賴的
(2)輸出(output)：告訴webpack在哪裏輸出他所創建的bundles，以及如何命名這些文件，默認爲./dist，基本上，整個應用程序結構，都會被編譯到你指定的輸出路徑的文件夾
(3)loader:讓webpack去處理那些非JS文件(webpack本身只理解JS),loader可以將所有類型文件轉換爲webpack能夠處理的有效模塊，然後就可以利用
webpack的打包能力，對他們進行處理
(4) 插件：使用時，require引入，然後把它添加到plugins數組中
三.webpack兩大特色：1.可以自動完成，2.loader可以處理各種類型的靜態文件，並且支持串聯操作 3，webpack是以commonJS的形式來書寫的，但對AMD/CMD支持也很全面
四，position有哪些屬性
1.absolute:生成絕對定位元素，相對於最近一級的定位不是static的父元素來進行定位
2.fixed:(老IE不支持)生成絕對定位的元素，通常對於瀏覽器窗口或frame進行定位
3.relative：生成相對定位的元素，相對於其在普通流中的位置進行定位
4.static:默認值，沒有定位，元素出現在正常流中
5.sticky:生成粘性定位的元素，容器的位置根據正常文檔流計算得知
五，TCP和UDP的區別
1.TCP處於傳輸層的協議，是傳輸控制協議，是基於連接的協議，也就是說，在正式收發數據前，必須和對方建立可靠的連接，一個TCP連接必須要經過
三次對話才能建立起來
2.UDP：用戶數據報協議，是與TCP相對應的協議，他是面向非連接的協議，他不與對方建立連接，而是直接把數據包發送過去，UDP適用於一次只傳少量數據，對可靠性要求不高的應用環境
區別：
(1)TCP面向有連接，UDP面向無連接
(2)TCP可靠，UDP不可靠
(3)TCP有序，UDP無序，消息在傳輸過程中可能會亂序，後發送的可能先達
(4)TCP無界，UDP有界，TCP通過字節流轉，UDP中每個包是單獨的
(5)TCP有流量控制(擁塞控制，三次握手)，UDP沒有
(6)TCP傳輸慢，UDP傳輸快，視頻流，廣播電視，在線多媒體都使用UDP
(7)TCP是重量級的，UDP是輕量級的
(8)TCP頭部比UDP大，TCP頭需20個字節，UDP頭只需8個字節
六，瀏覽器緩存
瀏覽器緩存分爲強緩存和協商緩存，當客戶端請求某個資源的時候，獲取緩存的流程如下：
1.先根據這個資源的一些http header判斷她是否命中強緩存，如果命中，則直接從本地獲取緩存資源，不會發送請求到服務端
2.當強緩存沒有命中的時候，客戶端會發送請求到服務器，服務器通過另一些request header驗證這個資源是否命中協商緩存，稱爲http再驗證，如果命中，服務器將請求返回，但不返回資源，而是告訴客戶端直接從緩存中獲取，客戶端收到返回後從緩存中獲取
3.強緩存和協商緩存的共同之處在於，如果命中緩存，服務器都不會返回資源
區別是：
1，強緩存不會發送請求到服務器，但協商緩存會
2.當ctrl+f5 強制刷新網頁時，直接從服務器加載，跳過強緩存和協商緩存
3.當f5刷新網頁時，跳過強緩存，但是會檢查協商緩存
強緩存：(以最新的爲準)
(1)Expires:(http1.0的規範) 緩存過期時間
(2)Cache-Control:max-age(http1.1規範) 緩存資源的最大生命週期
協商緩存：
(1)Last-Modified:最後更新時間，隨服務器response返回
(2)If-Modified-Since:通過比較兩個時間來判斷資源在兩次請求期間是否有過修改，如果沒有修改，則命中協商緩存
(3)ETag:資源內容的唯一標識，隨服務器返回
(4)If-None-Match:服務器通過比較請求頭部的If-None-Match與當前資源的ETag是否一致來判斷資源是否在兩次請求之間修改過
如果沒有修改，則命中協商緩存
七，React的生命週期
我認爲React的生命週期可以從三個方向考慮：
1.初次渲染的時候：Constructor=>getDefaultProps=>getInitialState=>ComponentWillMount=>render=>ComponentDidMount
2.第二次渲染的時候：getInitialState=>ComponentWillMount=>render=>ComponentDidMount
3.父組件props改變的時候：ComponentWillReceiveProps=>shouldComponentUpdate=>CompomentWillUpdate=>render=>ComponentDidUpdate
4.組件自身內部state改變的時候(this.setState)：shouldComponentUpdate=>ComponentWillUpdate=>render=>ComponentDidUpdate
5.最終在取消掛載的時候，都會執行ComponentWillUnMount
八，React的pureComponent和Component的區別
1.pureComponent是淺比較，只比較引用類型的地址是否一樣，而不比較其中的值是否還一樣
九，redux的實現原理
redux的實現原理(store,action,reducer)
1.觸發一個action
2.視圖發出一個action,action creater將這個action格式化並返回
3.這個action要麼被自動dispatch(配置時候使用bindActionCreators()),要麼由視圖層手動dispatch
4.store接收到這個action後，將當前的狀態樹和action傳給根reducer
5.根reducer將整個狀態樹切分成一個個小塊，然後將某一個小塊分發給知道怎麼處理這個小塊的子reducer
6.子reducer將傳入的小塊狀態樹進行拷貝，然後在副本上修改，並最終將修改後的副本返回給根reducer
7.當所有的子reducer返回他們修改好的副本後，根reducer將這些部分再次組合成一顆新的狀態樹，然後根reducer將這個新狀態樹交還給store，store再將自己的狀態設置爲這個新的狀態樹
8.store告訴視圖層，狀態更新了
9.視圖層綁定讓store把更新的狀態傳過來
10.視圖層綁定觸發了一個重新渲染的操作
設置redux:
(1)準備好store，根組件會創建store，並通過createStore(reducer)方法告訴store該使用哪一個根reducer,與此同時，根reducer也通過combineReducer()方法創建了一個向自己彙報的reducer團隊
(2)設置store和組件之間的通信。根組件將她的所有子組件包裹在<Provider>組件中，並建立了Provider與store之間的聯繫Provider本質上創建了一個用於更新視圖組建的網絡，那些智能組件通過connect方式連入這個網絡，以確保他們能夠獲取到狀態的更新
(3)準備好action callback，爲了讓木偶組件更好的處理action，智能組件可以使用bindActionCreators()方法來創建action callback。這樣做以後智能組件(容器型組件)就能給木偶組件(展示型組件)傳入一個回調，對應的action會在木偶組件調用這個回調的時候被自動dispatch
十，虛擬DOM DIFF
虛擬DOM實現，優點及原理，DIFF算法原理：
Diff算法有三個策略：
(1)(render tree)Web UI中DOM節點跨層次移動操作很少，可以忽略不計
(2)(component tree)擁有相同類的兩個組件會生成相似的樹型結構,擁有不同類的兩個組件會生成不同的樹形結構
(3) 對於同一層次的一組子節點，他們可以通過唯一的id進行區分
十一，Bind / call / apply的區別
1.這三個函數都是改變this的指向，第一個參數都是this,
2.call和apply比較類似，不同的是第二個參數，call接受的參數必須一個一個分開放入，apply的參數寫成一個數組
3.bind() 方法和前兩者不同在於： bind() 方法會返回執行上下文被改變的函數而不會立即執行，而前兩者是直接執行該函數。他的參數和call()相同。
十二，前端渲染和服務端渲染（ssr）區別
1，前端渲染路線：1. 請求一個html -> 2. 服務端返回一個html -> 3. 瀏覽器下載html裏面的js/css文件 -> 4. 等待js文件下載完成 -> 5. 等待js加載並初始化完成 -> 6. js代碼終於可以運行，由js代碼向後端請求數據( ajax/fetch ) -> 7. 等待後端數據返回 -> 8. react-dom( 客戶端 )從無到完整地，把數據渲染爲響應頁面
2，服務端渲染路線：2. 請求一個html -> 2. 服務端請求數據( 內網請求快 ) -> 3. 服務器初始渲染（服務端性能好，較快） -> 4. 服務端返回已經有正確內容的頁面 -> 5. 客戶端請求js/css文件 -> 6. 等待js文件下載完成 -> 7. 等待js加載並初始化完成 -> 8. react-dom( 客戶端 )把剩下一部分渲染完成( 內容小，渲染快 )
SSR即服務端渲染，簡單理解是將組件或頁面通過服務器生成html字符串，再發送到瀏覽器。與SPA相比，服務端渲染的優勢在於：利於SEO，減少頁面首屏加載時間。但是服務端渲染對服務器的壓力也是相對較大的，和服務器簡單輸出靜態文件相比，通過node去渲染出頁面再傳遞給客戶端顯然開銷是比較大的，需要注意準備好相應的服務器負載。