如何看待前端框架選型

對(duì)于同一個(gè)類(lèi)型的項(xiàng)目，采用開(kāi)發(fā)模式，使用的基本框架都是一致的。

前端技術(shù)選型：

（1）外部用戶(hù)的PC站；

（2）外部用戶(hù)的mobile站；

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

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

1、外部用戶(hù)的PC站

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

為什么使用jquery？

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

（2）是外部用戶(hù)，視覺(jué)體驗(yàn)高，權(quán)重高。適合先有行，再有行。就是說(shuō)視覺(jué)和行為要盡可能分離，會(huì)犧牲一點(diǎn)開(kāi)發(fā)成本，但是用戶(hù)更重要。

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

2、外部用戶(hù)的Mobile站

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

3、外部用戶(hù)的Native App開(kāi)發(fā)

前端組有直接參與 Native APP 開(kāi)發(fā)的項(xiàng)目，使用的是 React Native 進(jìn)行開(kāi)發(fā)。

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

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

（2）前期還是需要客戶(hù)端幫忙配合，項(xiàng)目搭建。

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

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

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

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

react生命周期

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

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

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

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

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

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

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

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

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

render:組件重新描繪

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

銷(xiāo)毀階段： componentWillUnmount:組件即將銷(xiāo)毀

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

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

diff算法實(shí)現(xiàn)

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

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

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

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

React 中 refs 的作用是什么？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

簡(jiǎn)述 flux 思想
Flux 的最大特點(diǎn)，就是數(shù)據(jù)的"單向流動(dòng)"。

用戶(hù)訪問(wèn) View

View 發(fā)出用戶(hù)的 Action

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

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

View 收到"change"事件后，更新頁(yè)面

React 項(xiàng)目用過(guò)什么腳手架
creat-react-app

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

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

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

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

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

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

2、并行編譯 happypack、thread-loader、uglifyjsWebpackPlugin開(kāi)啟并行

3、緩存 cache-loader、hard-source-webpack-plugin、uglifyjsWebpackPlugin開(kāi)啟緩存、babel-loader開(kāi)啟緩存

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

說(shuō)說(shuō)從輸入U(xiǎn)RL到看到頁(yè)面發(fā)生的全過(guò)程，越詳細(xì)越好
1、首先瀏覽器主進(jìn)程接管，開(kāi)了一個(gè)下載線程。

2、然后進(jìn)行HTTP請(qǐng)求（DNS查詢(xún)、IP尋址等等），中間會(huì)有三次捂手，等待響應(yīng)，開(kāi)始下載響應(yīng)報(bào)文。

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

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

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

6、css rule tree和dom tree生成完了之后，開(kāi)始合成render

7、tree，這個(gè)時(shí)候?yàn)g覽器會(huì)進(jìn)行l(wèi)ayout，開(kāi)始計(jì)算每一個(gè)節(jié)點(diǎn)的位置，然后進(jìn)行繪制。 繪制結(jié)束后，關(guān)閉TCP連接，過(guò)程有四次揮手

你剛剛說(shuō)了三次握手，四次揮手，那你描述一下？
（1）第一次握手：Client將標(biāo)志位SYN置為1，隨機(jī)產(chǎn)生一個(gè)值seq=J，并將該數(shù)據(jù)包發(fā)送給Server，Client進(jìn)入SYN_SENT狀態(tài)，等待Server確認(rèn)。 （2）第二次握手：Server收到數(shù)據(jù)包后由標(biāo)志位SYN=1知道Client請(qǐng)求建立連接，Server將標(biāo)志位SYN和ACK都置為1，ack=J+1，隨機(jī)產(chǎn)生一個(gè)值seq=K，并將該數(shù)據(jù)包發(fā)送給Client以確認(rèn)連接請(qǐng)求，Server進(jìn)入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進(jìn)入ESTABLISHED狀態(tài)，完成三次握手，隨后Client與Server之間可以開(kāi)始傳輸數(shù)據(jù)了。

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

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

2、絕對(duì)定位+margin反向偏移

3、絕對(duì)定位+transform反向偏移

4、display：tabel

5、display: flex

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

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

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

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

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

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

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

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

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

返回頭（response-header）：

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

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

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

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

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

Date： 時(shí)間

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

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

last-modified: 時(shí)間戳 文檔的最后改動(dòng)時(shí)間?？蛻?hù)可以通過(guò)If-Modified-Since請(qǐng)求頭提供一個(gè)日期，該請(qǐng)求將被視為一個(gè)條件GET，只有改動(dòng)時(shí)間遲于指定時(shí)間的文檔才會(huì)返回，否則返回一個(gè)304(Not Modified)狀態(tài)。Last-Modified也可用setDateHeader方法來(lái)設(shè)置。

expires 告訴瀏覽器把回送的資源緩存多長(zhǎng)時(shí)間 -1或0則是不緩存

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

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

// 注釋?zhuān)旱谝淮握?qǐng)求出來(lái)的數(shù)據(jù)先進(jìn)行緩存協(xié)商，是否緩存expires，cache-control 緩存時(shí)間，etag，last-modified等 //注釋?zhuān)憾啻卧L問(wèn)的時(shí)候，瀏覽器先判斷是否有緩存，是否過(guò)期 //未過(guò)期：直接從緩存中讀取。

//http狀態(tài)碼

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

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

識(shí)別入口文件

通過(guò)逐層識(shí)別模塊依賴(lài)。（Commonjs、amd或者es6的import，webpack都會(huì)對(duì)其進(jìn)行分析。來(lái)獲取代碼的依賴(lài)）

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

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

在 Webpack 運(yùn)行的生命周期中會(huì)廣播出許多事件，Plugin 可以監(jiān)聽(tīng)這些事件，在合適的時(shí)機(jī)通過(guò) Webpack 提供的 API 改變輸出結(jié)果

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

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

優(yōu)點(diǎn)：

前端耗時(shí)少。因?yàn)楹蠖似唇油炅薶tml，瀏覽器只需要直接渲染出來(lái)。 有利于SEO。因?yàn)樵诤蠖擞型暾膆tml頁(yè)面，所以爬蟲(chóng)更容易爬取獲得信息，更有利于seo。 無(wú)需占用客戶(hù)端資源。即解析模板的工作完全交由后端來(lái)做，客戶(hù)端只要解析標(biāo)準(zhǔn)的html頁(yè)面即可，這樣對(duì)于客戶(hù)端的資源占用更少，尤其是移動(dòng)端，也可以更省電。 后端生成靜態(tài)化文件。即生成緩存片段，這樣就可以減少數(shù)據(jù)庫(kù)查詢(xún)浪費(fèi)的時(shí)間了，且對(duì)于數(shù)據(jù)變化不大的頁(yè)面非常高效 。 缺點(diǎn)：

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

客戶(hù)端渲染的優(yōu)缺點(diǎn)是？ 優(yōu)點(diǎn)：

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

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

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

配合js查詢(xún)屏幕大小來(lái)改變html的font-size，

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

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

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

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

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

缺點(diǎn)：碰到重視高度的設(shè)計(jì)，或者重視元素間間距的設(shè)計(jì)，那就玩不開(kāi)了。

DOM節(jié)點(diǎn)類(lèi)型

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