如何看待前端框架選型

對于同一個類型的項目，采用開發(fā)模式，使用的基本框架都是一致的。

前端技術(shù)選型：

（1）外部用戶的PC站；

（2）外部用戶的mobile站；

（3）外部用戶的Native App開發(fā)；

（4）內(nèi)部員工的管理后臺

1、外部用戶的PC站

需要有SEO，有加載體驗，采用的是前后端分離開發(fā)模式，頁面直接渲染，基于jquery。

為什么使用jquery？

（1）主要是為了兼容IE8；

（2）是外部用戶，視覺體驗高，權(quán)重高。適合先有行，再有行。就是說視覺和行為要盡可能分離，會犧牲一點開發(fā)成本，但是用戶更重要。

（3）絕大多數(shù)頁面交互輕量用不上數(shù)據(jù)驅(qū)動。

2、外部用戶的Mobile站

這里說的Mobile站主要是瀏覽器訪問為主的，因此，頁面切換都是傳統(tǒng)連接跳轉(zhuǎn)，屬于傳統(tǒng)web應(yīng)用，前后端分離開發(fā)模式，頁面直接渲染，采用react。大致原因：使用react 是為了 和APP端的react native保持同步。

3、外部用戶的Native App開發(fā)

前端組有直接參與 Native APP 開發(fā)的項目，使用的是 React Native 進行開發(fā)。

為啥選擇RN，之前Hybrid模式開發(fā)有性能優(yōu)化瓶頸，采用React Native性能可以突破這個瓶頸，有原生的性能，且支持熱更新，上手不算太難，跨平臺，IOS和android代碼復(fù)用率90%。適合交互和動畫不太復(fù)雜的項目，最終要根據(jù)項目來。特別適合快速迭代的項目或者前期需要大量試錯的項目。

（1）不要隨意使用第三方庫，后期修改維護不方便，盡量自己寫還是自己寫；

（2）前期還是需要客戶端幫忙配合，項目搭建。

4、內(nèi)部員工的管理后臺

前后端分離開發(fā)，頁面?zhèn)戎禺惒戒秩?，使用vuejs。

大致內(nèi)容是：后臺管理系統(tǒng)有大量的增刪改查操作，適合具有雙向綁定的類庫或者框架進行渲染。同時沒有兼容性的要求（SEO，首屏渲染），因此單頁面是合適的。可以選擇vue，react，angular。因為vue對api，文檔對開發(fā)者更友好。選用好的UI組件，規(guī)范貫徹，拆分和按需加載，自動化測試有待加強。

對于比較正式的項目，前端技術(shù)選型策略一定是產(chǎn)品收益最大化，用戶在首位

react生命周期

react 生命周期函數(shù) 初始化階段：

getDefaultProps:獲取實例的默認(rèn)屬性

getInitialState:獲取每個實例的初始化狀態(tài)

componentWillMount：組件即將被裝載、渲染到頁面上

render:組件在這里生成虛擬的 DOM 節(jié)點

componentDidMount:組件真正在被裝載之后 運行中狀態(tài)：

componentWillReceiveProps:組件將要接收到屬性的時候調(diào)用

shouldComponentUpdate:組件接受到新屬性或者新狀態(tài)的時候（可以返回 false，接收數(shù)據(jù)后不更新，阻止 render 調(diào)用，后面的函數(shù)不會被繼續(xù)執(zhí)行了）

componentWillUpdate:組件即將更新不能修改屬性和狀態(tài)

render:組件重新描繪

componentDidUpdate:組件已經(jīng)更新

銷毀階段： componentWillUnmount:組件即將銷毀

react 的虛擬dom是怎么實現(xiàn)的?diff算法?

首先說說為什么要使用Virturl DOM，因為操作真實DOM的耗費的性能代價太高，所以react內(nèi)部使用js實現(xiàn)了一套dom結(jié)構(gòu)，在每次操作在和真實dom之前，使用實現(xiàn)好的diff算法，對虛擬dom進行比較，遞歸找出有變化的dom節(jié)點，然后對其進行更新操作。為了實現(xiàn)虛擬DOM，我們需要把每一種節(jié)點類型抽象成對象，每一種節(jié)點類型有自己的屬性，也就是prop，每次進行diff的時候，react會先比較該節(jié)點類型，假如節(jié)點類型不一樣，那么react會直接刪除該節(jié)點，然后直接創(chuàng)建新的節(jié)點插入到其中，假如節(jié)點類型一樣，那么會比較prop是否有更新，假如有prop不一樣，那么react會判定該節(jié)點有更新，那么重渲染該節(jié)點，然后在對其子節(jié)點進行比較，一層一層往下，直到?jīng)]有子節(jié)點。

diff算法實現(xiàn)

把樹形結(jié)構(gòu)按照層級分解，只比較同級元素。

給列表結(jié)構(gòu)的每個單元添加唯一的 key 屬性，方便比較。

React 只會匹配相同 class 的 component（這里面的 class 指的是組件的名字）

合并操作，調(diào)用 component 的 setState 方法的時候, React 將其標(biāo)記為 dirty.到每一個事件循環(huán)結(jié)束, React 檢查所有標(biāo)記 dirty 的 component 重新繪制. 選擇性子樹渲染。開發(fā)人員可以重寫 shouldComponentUpdate 提高 diff 的性能。

React 中 refs 的作用是什么？

Refs 是 React 提供給我們的安全訪問 DOM 元素或者某個組件實例的句柄。我們可以為元素添加 ref 屬性然后在回調(diào)函數(shù)中接受該元素在 DOM 樹中的句柄，該值會作為回調(diào)函數(shù)的第一個參數(shù)返回

React 中有三種構(gòu)建組件的方式

React.createClass()、ES6 class 和無狀態(tài)函數(shù)。

react 組件的劃分業(yè)務(wù)組件技術(shù)組件？

根據(jù)組件的職責(zé)通常把組件分為 UI 組件和容器組件。

UI 組件負(fù)責(zé) UI 的呈現(xiàn)，容器組件負(fù)責(zé)管理數(shù)據(jù)和邏輯。

兩者通過 React-Redux 提供 connect 方法聯(lián)系起來。

應(yīng)該在 React 組件的何處發(fā)起 Ajax 請求

在 React 組件中，應(yīng)該在 componentDidMount 中發(fā)起網(wǎng)絡(luò)請求。這個方法會在組件第一次“掛載”(被添加到 DOM)時執(zhí)行，在組件的生命周期中僅會執(zhí)行一次。更重要的是，你不能保證在組件掛載之前 Ajax 請求已經(jīng)完成，如果是這樣，也就意味著你將嘗試在一個未掛載的組件上調(diào)用 setState，這將不起作用。在 componentDidMount 中發(fā)起網(wǎng)絡(luò)請求將保證這有一個組件可以更新了

描述事件在 React 中的處理方式。

為了解決跨瀏覽器兼容性問題，您的 React 中的事件處理程序?qū)鬟f SyntheticEvent 的實例，它是 React 的瀏覽器本機事件的跨瀏覽器包裝器。

這些 SyntheticEvent 與您習(xí)慣的原生事件具有相同的接口，除了它們在所有瀏覽器中都兼容。有趣的是，React 實際上并沒有將事件附加到子節(jié)點本身。React 將使用單個事件監(jiān)聽器監(jiān)聽頂層的所有事件。這對于性能是有好處的，這也意味著在更新 DOM 時，React 不需要擔(dān)心跟蹤事件監(jiān)聽器。

react 的渲染過程中，兄弟節(jié)點之間是怎么處理的？也就是key值不一樣的時候。

通常我們輸出節(jié)點的時候都是map一個數(shù)組然后返回一個ReactNode，為了方便react內(nèi)部進行優(yōu)化，我們必須給每一個reactNode添加key，這個key prop在設(shè)計值處不是給開發(fā)者用的，而是給react用的，大概的作用就是給每一個reactNode添加一個身份標(biāo)識，方便react進行識別，在重渲染過程中，如果key一樣，若組件屬性有所變化，則react只更新組件對應(yīng)的屬性；沒有變化則不更新，如果key不一樣，則react先銷毀該組件，然后重新創(chuàng)建該組件。

React 中 keys 的作用是什么？
開發(fā)過程中，我們需要保證某個元素的 key 在其同級元素中具有唯一性。在 React Diff 算法中 React 會借助元素的 Key 值來判斷該元素是新近創(chuàng)建的還是被移動而來的元素，從而減少不必要的元素重渲染。此外，React 還需要借助 Key 值來判斷元素與本地狀態(tài)的關(guān)聯(lián)關(guān)系，因此我們絕不可忽視轉(zhuǎn)換函數(shù)中 Key 的重要性。

調(diào)用 setState 之后發(fā)生了什么？
在代碼中調(diào)用 setState 函數(shù)之后，React 會將傳入的參數(shù)對象與組件當(dāng)前的狀態(tài)合并，然后觸發(fā)所謂的調(diào)和過程（Reconciliation）。經(jīng)過調(diào)和過程，React 會以相對高效的方式根據(jù)新的狀態(tài)構(gòu)建 React 元素樹并且著手重新渲染整個 UI 界面。在 React 得到元素樹之后，React 會自動計算出新的樹與老樹的節(jié)點差異，然后根據(jù)差異對界面進行最小化重渲染。在差異計算算法中，React 能夠相對精確地知道哪些位置發(fā)生了改變以及應(yīng)該如何改變，這就保證了按需更新，而不是全部重新渲染。

shouldComponentUpdate 是做什么的，（react 性能優(yōu)化是哪個周期函數(shù)？）
shouldComponentUpdate 這個方法用來判斷是否需要調(diào)用 render 方法重新描繪 dom。因為 dom 的描繪非常消耗性能，如果我們能在 shouldComponentUpdate 方法中能夠?qū)懗龈鼉?yōu)化的 dom diff 算法，可以極大的提高性能。

為什么虛擬 dom 會提高性能?(必考)
虛擬 dom 相當(dāng)于在 js 和真實 dom 中間加了一個緩存，利用 dom diff 算法避免了沒有必要的 dom 操作，從而提高性能。

用 JavaScript 對象結(jié)構(gòu)表示 DOM 樹的結(jié)構(gòu)；然后用這個樹構(gòu)建一個真正的 DOM 樹，插到文檔當(dāng)中當(dāng)狀態(tài)變更的時候，重新構(gòu)造一棵新的對象樹。然后用新的樹和舊的樹進行比較，記錄兩棵樹差異把 2 所記錄的差異應(yīng)用到步驟 1 所構(gòu)建的真正的 DOM 樹上，視圖就更新了。

React 中 refs 的作用是什么？
Refs 是 React 提供給我們的安全訪問 DOM 元素或者某個組件實例的句柄。我們可以為元素添加 ref 屬性然后在回調(diào)函數(shù)中接受該元素在 DOM 樹中的句柄，該值會作為回調(diào)函數(shù)的第一個參數(shù)返回：

展示組件(Presentational component)和容器組件(Container component)之間有何不同
展示組件關(guān)心組件看起來是什么。展示專門通過 props 接受數(shù)據(jù)和回調(diào)，并且?guī)缀醪粫凶陨淼臓顟B(tài)，但當(dāng)展示組件擁有自身的狀態(tài)時，通常也只關(guān)心 UI 狀態(tài)而不是數(shù)據(jù)的狀態(tài)。

容器組件則更關(guān)心組件是如何運作的。容器組件會為展示組件或者其它容器組件提供數(shù)據(jù)和行為(behavior)，它們會調(diào)用 Flux actions，并將其作為回調(diào)提供給展示組件。容器組件經(jīng)常是有狀態(tài)的，因為它們是(其它組件的)數(shù)據(jù)源。

類組件(Class component)和函數(shù)式組件(Functional component)之間有何不同
類組件不僅允許你使用更多額外的功能，如組件自身的狀態(tài)和生命周期鉤子，也能使組件直接訪問 store 并維持狀態(tài)

當(dāng)組件僅是接收 props，并將組件自身渲染到頁面時，該組件就是一個 '無狀態(tài)組件(stateless component)'，可以使用一個純函數(shù)來創(chuàng)建這樣的組件。這種組件也被稱為啞組件(dumb components)或展示組件

(組件的)狀態(tài)(state)和屬性(props)之間有何不同
State 是一種數(shù)據(jù)結(jié)構(gòu)，用于組件掛載時所需數(shù)據(jù)的默認(rèn)值。State 可能會隨著時間的推移而發(fā)生突變，但多數(shù)時候是作為用戶事件行為的結(jié)果。

Props(properties 的簡寫)則是組件的配置。props 由父組件傳遞給子組件，并且就子組件而言，props 是不可變的(immutable)。組件不能改變自身的 props，但是可以把其子組件的 props 放在一起(統(tǒng)一管理)。Props 也不僅僅是數(shù)據(jù)--回調(diào)函數(shù)也可以通過 props 傳遞。

何為受控組件(controlled component)
在 HTML 中，類似 input, textarea 和 select> 這樣的表單元素會維護自身的狀態(tài)，并基于用戶的輸入來更新。當(dāng)用戶提交表單時，前面提到的元素的值將隨表單一起被發(fā)送。但在 React 中會有些不同，包含表單元素的組件將會在 state 中追蹤輸入的值，并且每次調(diào)用回調(diào)函數(shù)時，如 onChange 會更新 state，重新渲染組件。一個輸入表單元素，它的值通過 React 的這種方式來控制，這樣的元素就被稱為"受控元素"。

何為高階組件(higher order component)
高階組件是一個以組件為參數(shù)并返回一個新組件的函數(shù)。HOC 運行你重用代碼、邏輯和引導(dǎo)抽象。最常見的可能是 Redux 的 connect 函數(shù)。除了簡單分享工具庫和簡單的組合，HOC 最好的方式是共享 React 組件之間的行為。如果你發(fā)現(xiàn)你在不同的地方寫了大量代碼來做同一件事時，就應(yīng)該考慮將代碼重構(gòu)為可重用的 HOC。

為什么建議傳遞給 setState 的參數(shù)是一個 callback 而不是一個對象
因為 this.props 和 this.state 的更新可能是異步的，不能依賴它們的值去計算下一個 state。

除了在構(gòu)造函數(shù)中綁定 this，還有其它方式嗎
你可以使用屬性初始值設(shè)定項(property initializers)來正確綁定回調(diào)，create-react-app 也是默認(rèn)支持的。在回調(diào)中你可以使用箭頭函數(shù)，但問題是每次組件渲染時都會創(chuàng)建一個新的回調(diào)。

(在構(gòu)造函數(shù)中)調(diào)用 super(props) 的目的是什么
在 super() 被調(diào)用之前，子類是不能使用 this 的，在 ES2015 中，子類必須在 constructor 中調(diào)用 super()。傳遞 props 給 super() 的原因則是便于(在子類中)能在 constructor 訪問 this.props。

createElement 和 cloneElement 有什么區(qū)別？
React.createElement():JSX 語法就是用 React.createElement()來構(gòu)建 React 元素的。它接受三個參數(shù)，第一個參數(shù)可以是一個標(biāo)簽名。如 div、span，或者 React 組件。第二個參數(shù)為傳入的屬性。第三個以及之后的參數(shù)，皆作為組件的子組件。

React.cloneElement()與 React.createElement()相似，不同的是它傳入的第一個參數(shù)是一個 React 元素，而不是標(biāo)簽名或組件。新添加的屬性會并入原有的屬性，傳入到返回的新元素中，而就的子元素獎杯替換。

簡述 flux 思想
Flux 的最大特點，就是數(shù)據(jù)的"單向流動"。

用戶訪問 View

View 發(fā)出用戶的 Action

Dispatcher 收到 Action，要求 Store 進行相應(yīng)的更新

Store 更新后，發(fā)出一個"change"事件

View 收到"change"事件后，更新頁面

React 項目用過什么腳手架
creat-react-app

了解 redux 么，說一下 redux 把
redux 是一個應(yīng)用數(shù)據(jù)流框架，主要是解決了組件間狀態(tài)共享的問題，原理是集中式管理，主要有三個核心方法，action，store，reducer，工作流程是 view 調(diào)用 store 的 dispatch 接收 action 傳入 store，reducer 進行 state 操作，view 通過 store 提供的 getState 獲取最新的數(shù)據(jù)，flux 也是用來進行數(shù)據(jù)操作的，有四個組成部分 action，dispatch，view，store，工作流程是 view 發(fā)出一個 action，派發(fā)器接收 action，讓 store 進行數(shù)據(jù)更新，更新完成以后 store 發(fā)出 change，view 接受 change 更新視圖。Redux 和 Flux 很像。主要區(qū)別在于 Flux 有多個可以改變應(yīng)用狀態(tài)的 store，在 Flux 中 dispatcher 被用來傳遞數(shù)據(jù)到注冊的回調(diào)事件，但是在 redux 中只能定義一個可更新狀態(tài)的 store，redux 把 store 和 Dispatcher 合并,結(jié)構(gòu)更加簡單清晰

新增 state,對狀態(tài)的管理更加明確，通過 redux，流程更加規(guī)范了，減少手動編碼量，提高了編碼效率，同時缺點時當(dāng)數(shù)據(jù)更新時有時候組件不需要，但是也要重新繪制，有些影響效率。一般情況下，我們在構(gòu)建多交互，多數(shù)據(jù)流的復(fù)雜項目應(yīng)用時才會使用它們

redux 有什么缺點
一個組件所需要的數(shù)據(jù)，必須由父組件傳過來，而不能像 flux 中直接從 store 取。

當(dāng)一個組件相關(guān)數(shù)據(jù)更新時，即使父組件不需要用到這個組件，父組件還是會重新 render，可能會有效率影響，或者需要寫復(fù)雜的 shouldComponentUpdate 進行判斷。

我現(xiàn)在有一個數(shù)組[1,2,3,4]，請實現(xiàn)算法，得到這個數(shù)組的全排列的數(shù)組，如[2,1,3,4]，[2,1,4,3]。。。。你這個算法的時間復(fù)雜度是多少
將每一個數(shù)組拆除倆個小數(shù)組進行求它的全排列，然后得到的結(jié)果互相之間又進行全排列，然后把最后的結(jié)果連接起來

你說一下webpack的一些plugin，怎么使用webpack對項目進行優(yōu)化
構(gòu)建優(yōu)化 1、減少編譯體積 ContextReplacementPugin、IgnorePlugin、babel-plugin-import、babel-plugin-transform-runtime。

2、并行編譯 happypack、thread-loader、uglifyjsWebpackPlugin開啟并行

3、緩存 cache-loader、hard-source-webpack-plugin、uglifyjsWebpackPlugin開啟緩存、babel-loader開啟緩存

4、預(yù)編譯 dllWebpackPlugin && DllReferencePlugin、auto-dll-webapck-plugin

性能優(yōu)化 1、減少編譯體積 Tree-shaking、Scope Hositing。

2、hash緩存 webpack-md5-plugin

3、拆包 splitChunksPlugin、import()、require.ensure

說說從輸入URL到看到頁面發(fā)生的全過程，越詳細(xì)越好
1、首先瀏覽器主進程接管，開了一個下載線程。

2、然后進行HTTP請求（DNS查詢、IP尋址等等），中間會有三次捂手，等待響應(yīng)，開始下載響應(yīng)報文。

3、將下載完的內(nèi)容轉(zhuǎn)交給Renderer進程管理。

4、Renderer進程開始解析css rule tree和dom tree，這兩個過程是并行的，所以一般我會把link標(biāo)簽放在頁面頂部。

5、解析繪制過程中，當(dāng)瀏覽器遇到link標(biāo)簽或者script、img等標(biāo)簽，瀏覽器會去下載這些內(nèi)容，遇到時候緩存的使用緩存，不適用緩存的重新下載資源。

6、css rule tree和dom tree生成完了之后，開始合成render

7、tree，這個時候瀏覽器會進行l(wèi)ayout，開始計算每一個節(jié)點的位置，然后進行繪制。 繪制結(jié)束后，關(guān)閉TCP連接，過程有四次揮手

你剛剛說了三次握手，四次揮手，那你描述一下？
（1）第一次握手：Client將標(biāo)志位SYN置為1，隨機產(chǎn)生一個值seq=J，并將該數(shù)據(jù)包發(fā)送給Server，Client進入SYN_SENT狀態(tài)，等待Server確認(rèn)。 （2）第二次握手：Server收到數(shù)據(jù)包后由標(biāo)志位SYN=1知道Client請求建立連接，Server將標(biāo)志位SYN和ACK都置為1，ack=J+1，隨機產(chǎn)生一個值seq=K，并將該數(shù)據(jù)包發(fā)送給Client以確認(rèn)連接請求，Server進入SYN_RCVD狀態(tài)。 （3）第三次握手：Client收到確認(rèn)后，檢查ack是否為J+1，ACK是否為1，如果正確則將標(biāo)志位ACK置為1，ack=K+1，并將該數(shù)據(jù)包發(fā)送給Server，Server檢查ack是否為K+1，ACK是否為1，如果正確則連接建立成功，Client和Server進入ESTABLISHED狀態(tài)，完成三次握手，隨后Client與Server之間可以開始傳輸數(shù)據(jù)了。

1）第一次揮手：Client發(fā)送一個FIN，用來關(guān)閉Client到Server的數(shù)據(jù)傳送，Client進入FIN_WAIT_1狀態(tài)。 （2）第二次揮手：Server收到FIN后，發(fā)送一個ACK給Client，確認(rèn)序號為收到序號+1（與SYN相同，一個FIN占用一個序號），Server進入CLOSE_WAIT狀態(tài)。 （3）第三次揮手：Server發(fā)送一個FIN，用來關(guān)閉Server到Client的數(shù)據(jù)傳送，Server進入LAST_ACK狀態(tài)。 （4）第四次揮手：Client收到FIN后，Client進入TIME_WAIT狀態(tài)，接著發(fā)送一個ACK給Server，確認(rèn)序號為收到序號+1，Server進入CLOSED狀態(tài)，完成四次揮手。

CSS中幾種垂直水平居中的方式
1、絕對定位+margin：auto

2、絕對定位+margin反向偏移

3、絕對定位+transform反向偏移

4、display：tabel

5、display: flex

react和vue的比較
觀察者模式實現(xiàn) ?
http報文頭部有哪些字段? 有什么意義 ?
請求頭（Request）：

Accept：text/html application/xml 告訴服務(wù)器客戶端瀏覽器這邊可以出里什么數(shù)據(jù)；

Accept-Encodeing：gzip 告訴服務(wù)器我能支持什么樣的壓縮格式

accept-language：告訴服務(wù)器瀏覽器支持的語言

Cache-control：告訴服務(wù)器是否緩存

Connection:keep-alive 告訴服務(wù)器當(dāng)前保持活躍（與服務(wù)器處于鏈接狀態(tài)）

Host：遠(yuǎn)程服務(wù)器的域名

User-agent：客戶端的一些信息，瀏覽器信息 版本

referer：當(dāng)前頁面上一個頁面地址。一般用于服務(wù)器判斷是否為同一個域名下的請求

返回頭（response-header）：

cache-control:private/no-cache; 私有的不需要緩存/no-cache也不需要緩存

connection:keep-live; 服務(wù)器同意保持連接

content-Enconding：gzip；除去頭的剩余部分壓縮返回格式

content-length:內(nèi)容長度

content-type：text/css;返回內(nèi)容支持格式

Date： 時間

server：ngnix 服務(wù)器類型

set-Cookie:服務(wù)器向客戶端設(shè)置cookie 第一次訪問服務(wù)器會下發(fā)cookie當(dāng)作身份認(rèn)證信息，第二次訪問服務(wù)器再把cookie送給服務(wù)器，可以當(dāng)作認(rèn)證信息

last-modified: 時間戳 文檔的最后改動時間。客戶可以通過If-Modified-Since請求頭提供一個日期，該請求將被視為一個條件GET，只有改動時間遲于指定時間的文檔才會返回，否則返回一個304(Not Modified)狀態(tài)。Last-Modified也可用setDateHeader方法來設(shè)置。

expires 告訴瀏覽器把回送的資源緩存多長時間 -1或0則是不緩存

etag:版本專有的加密指紋。（有的網(wǎng)站不用，并非必須）優(yōu)先檢查etag再檢查last-modif

ied的時間戳。向服務(wù)器請求帶if-none-match,服務(wù)器判斷是否過期未過期返回304，過期返回200

// 注釋：第一次請求出來的數(shù)據(jù)先進行緩存協(xié)商，是否緩存expires，cache-control 緩存時間，etag，last-modified等 //注釋：多次訪問的時候，瀏覽器先判斷是否有緩存，是否過期 //未過期：直接從緩存中讀取。

//http狀態(tài)碼

//1.指示信息–表示請求已經(jīng)接受，繼續(xù)處理 //2.成功–表示請求已經(jīng)被成功接受，理解 //3.重定向–表示完成請求必須進行更進一步操作 //4.客戶端錯誤–請求有語法錯誤或者請求無法實現(xiàn) //5.服務(wù)器端錯誤–服務(wù)器未能實現(xiàn)合法的請求

移動端高清方案如何解決 ?
webpack的原理, loader 和 plugin 是干什么的? 有自己手寫過么 ?
1.2 打包原理

識別入口文件

通過逐層識別模塊依賴。（Commonjs、amd或者es6的import，webpack都會對其進行分析。來獲取代碼的依賴）

webpack做的就是分析代碼。轉(zhuǎn)換代碼，編譯代碼，輸出代碼 最終形成打包后的代碼

loader是文件加載器，能夠加載資源文件，并對這些文件進行一些處理，諸如編譯、壓縮等，最終一起打包到指定的文件中

在 Webpack 運行的生命周期中會廣播出許多事件，Plugin 可以監(jiān)聽這些事件，在合適的時機通過 Webpack 提供的 API 改變輸出結(jié)果

SSR 和 客戶端渲染有什么區(qū)別 , vue是如何實現(xiàn)綁定事件的 ?
客戶端渲染和服務(wù)器端渲染的最重要的區(qū)別就是究竟是誰來完成html文件的完整拼接，如果是在服務(wù)器端完成的，然后返回給客戶端，就是服務(wù)器端渲染，而如果是前端做了更多的工作完成了html的拼接，則就是客戶端渲染。

服務(wù)器端渲染的優(yōu)缺點是？

優(yōu)點：

前端耗時少。因為后端拼接完了html，瀏覽器只需要直接渲染出來。 有利于SEO。因為在后端有完整的html頁面，所以爬蟲更容易爬取獲得信息，更有利于seo。 無需占用客戶端資源。即解析模板的工作完全交由后端來做，客戶端只要解析標(biāo)準(zhǔn)的html頁面即可，這樣對于客戶端的資源占用更少，尤其是移動端，也可以更省電。 后端生成靜態(tài)化文件。即生成緩存片段，這樣就可以減少數(shù)據(jù)庫查詢浪費的時間了，且對于數(shù)據(jù)變化不大的頁面非常高效 。 缺點：

不利于前后端分離，開發(fā)效率低。使用服務(wù)器端渲染，則無法進行分工合作，則對于前端復(fù)雜度高的項目，不利于項目高效開發(fā)。另外，如果是服務(wù)器端渲染，則前端一般就是寫一個靜態(tài)html文件，然后后端再修改為模板，這樣是非常低效的，并且還常常需要前后端共同完成修改的動作； 或者是前端直接完成html模板，然后交由后端。另外，如果后端改了模板，前端還需要根據(jù)改動的模板再調(diào)節(jié)css，這樣使得前后端聯(lián)調(diào)的時間增加。 占用服務(wù)器端資源。即服務(wù)器端完成html模板的解析，如果請求較多，會對服務(wù)器造成一定的訪問壓力。而如果使用前端渲染，就是把這些解析的壓力分?jǐn)偭饲岸耍@里確實完全交給了一個服務(wù)器。

客戶端渲染的優(yōu)缺點是？ 優(yōu)點：

前后端分離。前端專注于前端UI，后端專注于api開發(fā)，且前端有更多的選擇性，而不需要遵循后端特定的模板。 體驗更好。比如，我們將網(wǎng)站做成SPA或者部分內(nèi)容做成SPA，這樣，尤其是移動端，可以使體驗更接近于原生app。 缺點：

前端響應(yīng)較慢。如果是客戶端渲染，前端還要進行拼接字符串的過程，需要耗費額外的時間，不如服務(wù)器端渲染速度快。 不利于SEO。目前比如百度、谷歌的爬蟲對于SPA都是不認(rèn)的，只是記錄了一個頁面，所以SEO很差。因為服務(wù)器端可能沒有保存完整的html，而是前端通過js進行dom的拼接，那么爬蟲無法爬取信息。 除非搜索引擎的seo可以增加對于JavaScript的爬取能力，這才能保證seo。

移動端rem布局如何實現(xiàn)? 簡述原理?
原理是，先按定高寬設(shè)計出來頁面，然后轉(zhuǎn)換為rem單位，

配合js查詢屏幕大小來改變html的font-size，

最終做出所謂的完美自適應(yīng)。

rem+js是寬度自適應(yīng)，無法做到高度自適應(yīng)，所以那些對高度要求很高的rem+js無法實現(xiàn)。

改變?yōu)g覽器寬度，你會發(fā)現(xiàn)，頁面所有元素的高寬都等比例縮放，

也就是大屏幕下導(dǎo)航是橫的，小屏幕下還是橫的只不過變小了。。

優(yōu)點：理想狀態(tài)是所有屏幕的高寬比和最初的設(shè)計高寬比一樣，或者相差不多，完美適應(yīng)。

缺點：碰到重視高度的設(shè)計，或者重視元素間間距的設(shè)計，那就玩不開了。

DOM節(jié)點類型

到此這篇關(guān)于React面試題小結(jié)的文章就介紹到這了,更多相關(guān)React面試題內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持腳本之家！

最新評論