一、CSS相關

#1.1 左邊定寬，右邊自適應方案：float + margin，float + calc

/* 方案1 */ .left {width: 120px;float: left; } .right {margin-left: 120px; } /* 方案2 */ .left {width: 120px;float: left; } .right {width: calc(100% - 120px);float: left; }

#1.2 左右兩邊定寬，中間自適應：float，float + calc, 圣杯布局（設置BFC，margin負值法），flex

.wrap {width: 100%;height: 200px; } .wrap > div {height: 100%; } /* 方案1 */ .left {width: 120px;float: left; } .right {float: right;width: 120px; } .center {margin: 0 120px; } /* 方案2 */ .left {width: 120px;float: left; } .right {float: right;width: 120px; } .center {width: calc(100% - 240px);margin-left: 120px; } /* 方案3 */ .wrap {display: flex; } .left {width: 120px; } .right {width: 120px; } .center {flex: 1; }

#1.3 左右居中

• 行內(nèi)元素:?text-align: center
• 定寬塊狀元素: 左右?margin?值為?auto
• 不定寬塊狀元素:?table布局，position + transform

/* 方案1 */ .wrap {text-align: center } .center {display: inline;/* or *//* display: inline-block; */ } /* 方案2 */ .center {width: 100px;margin: 0 auto; } /* 方案2 */ .wrap {position: relative; } .center {position: absulote;left: 50%;transform: translateX(-50%); }

#1.4 上下垂直居中

• 定高：margin，position + margin(負值)
• 不定高：position?+?transform，flex，IFC + vertical-align:middle

/* 定高方案1 */ .center {height: 100px;margin: 50px 0; } /* 定高方案2 */ .center {height: 100px;position: absolute;top: 50%;margin-top: -25px; } /* 不定高方案1 */ .center {position: absolute;top: 50%;transform: translateY(-50%); } /* 不定高方案2 */ .wrap {display: flex;align-items: center; } .center {width: 100%; } /* 不定高方案3 */ /* 設置 inline-block 則會在外層產(chǎn)生 IFC，高度設為 100% 撐開 wrap 的高度 */ .wrap::before {content: '';height: 100%;display: inline-block;vertical-align: middle; } .wrap {text-align: center; } .center {display: inline-block; vertical-align: middle; }

#1.5 盒模型：content（元素內(nèi)容） + padding（內(nèi)邊距） + border（邊框） + margin（外邊距）

延伸：?box-sizing

• content-box：默認值，總寬度 =?margin?+?border?+?padding?+?width
• border-box：盒子寬度包含?padding?和?border，總寬度 = margin + width
• inherit：從父元素繼承?box-sizing?屬性

#1.6 BFC、IFC、GFC、FFC：FC（Formatting Contexts），格式化上下文

BFC：塊級格式化上下文，容器里面的子元素不會在布局上影響到外面的元素，反之也是如此(按照這個理念來想，只要脫離文檔流，肯定就能產(chǎn)生?BFC)。產(chǎn)生?BFC?方式如下

• float?的值不為?none。
• overflow?的值不為?visible。
• position?的值不為?relative?和?static。
• display?的值為?table-cell,?table-caption,?inline-block中的任何一個

用處？常見的多欄布局，結合塊級別元素浮動，里面的元素則是在一個相對隔離的環(huán)境里運行

IFC：內(nèi)聯(lián)格式化上下文，IFC?的?line?box（線框）高度由其包含行內(nèi)元素中最高的實際高度計算而來（不受到豎直方向的?padding/margin?影響)。

IFC中的line box一般左右都貼緊整個?IFC，但是會因為?float?元素而擾亂。float?元素會位于 IFC 與?line box?之間，使得?line box?寬度縮短。 同個?ifc?下的多個?line box?高度會不同。?IFC中時不可能有塊級元素的，當插入塊級元素時（如?p?中插入?div）會產(chǎn)生兩個匿名塊與?div?分隔開，即產(chǎn)生兩個?IFC?，每個?IFC?對外表現(xiàn)為塊級元素，與?div?垂直排列。

用處？

• 水平居中：當一個塊要在環(huán)境中水平居中時，設置其為?inline-block?則會在外層產(chǎn)生IFC，通過?text-align?則可以使其水平居中。
• 垂直居中：創(chuàng)建一個?IFC，用其中一個元素撐開父元素的高度，然后設置其?vertical-align:?middle，其他行內(nèi)元素則可以在此父元素下垂直居中

• GFC：網(wǎng)格布局格式化上下文（display: grid）
• FFC：自適應格式化上下文（display: flex）

#二、JS 基礎（ES5）

#2.1 原型

這里可以談很多，只要圍繞?[[ prototype ]]?談，都沒啥問題

#2.2 閉包

牽扯作用域，可以兩者聯(lián)系起來一起談

#2.3 作用域

詞法作用域，動態(tài)作用域

#2.4 this

不同情況的調(diào)用，this指向分別如何。順帶可以提一下?es6?中箭頭函數(shù)沒有?this,?arguments,?super?等，這些只依賴包含箭頭函數(shù)最接近的函數(shù)

#2.5 call，apply，bind 三者用法和區(qū)別

參數(shù)、綁定規(guī)則（顯示綁定和強綁定），運行效率（最終都會轉(zhuǎn)換成一個一個的參數(shù)去運行）、運行情況（call，apply?立即執(zhí)行，bind?是return?出一個?this?“固定”的函數(shù)，這也是為什么?bind?是強綁定的一個原因）

注：“固定”這個詞的含義，它指的固定是指只要傳進去了?context，則?bind?中?return?出來的函數(shù)?this?便一直指向?context，除非?context?是個變量

#2.6 變量聲明提升

js?代碼在運行前都會進行?AST?解析，函數(shù)申明默認會提到當前作用域最前面，變量申明也會進行提升。但賦值不會得到提升。關于?AST?解析，這里也可以說是形成詞法作用域的主要原因

#三、JS 基礎（ES6）

#3.1 let，const

let?產(chǎn)生塊級作用域（通常配合?for?循環(huán)或者?{}?進行使用產(chǎn)生塊級作用域），const?申明的變量是常量（內(nèi)存地址不變）

#3.2 Promise

這里你談?promise的時候，除了將他解決的痛點以及常用的?API?之外，最好進行拓展把?eventloop?帶進來好好講一下，microtask(微任務)、macrotask(任務) 的執(zhí)行順序，如果看過?promise?源碼，最好可以談一談 原生?Promise?是如何實現(xiàn)的。Promise?的關鍵點在于callback?的兩個參數(shù)，一個是?resovle，一個是?reject。還有就是?Promise?的鏈式調(diào)用（Promise.then()，每一個?then?都是一個責任人）

#3.3 Generator

遍歷器對象生成函數(shù)，最大的特點是可以交出函數(shù)的執(zhí)行權

• function?關鍵字與函數(shù)名之間有一個星號；
• 函數(shù)體內(nèi)部使用?yield表達式，定義不同的內(nèi)部狀態(tài)；
• next指針移向下一個狀態(tài)

這里你可以說說?Generator的異步編程，以及它的語法糖?async?和?awiat，傳統(tǒng)的異步編程。ES6?之前，異步編程大致如下

• 回調(diào)函數(shù)
• 事件監(jiān)聽
• 發(fā)布/訂閱

傳統(tǒng)異步編程方案之一：協(xié)程，多個線程互相協(xié)作，完成異步任務。

#3.4 async、await

Generator?函數(shù)的語法糖。有更好的語義、更好的適用性、返回值是?Promise。

• async => *
• await => yield

// 基本用法async function timeout (ms) {await new Promise((resolve) => {setTimeout(resolve, ms) }) } async function asyncConsole (value, ms) {await timeout(ms)console.log(value) } asyncConsole('hello async and await', 1000)

注：最好把2，3，4 連到一起講

#3.5 AMD，CMD，CommonJs，ES6 Module：解決原始無模塊化的痛點

• AMD：requirejs?在推廣過程中對模塊定義的規(guī)范化產(chǎn)出，提前執(zhí)行，推崇依賴前置
• CMD：seajs?在推廣過程中對模塊定義的規(guī)范化產(chǎn)出，延遲執(zhí)行，推崇依賴就近
• CommonJs：模塊輸出的是一個值的?copy，運行時加載，加載的是一個對象（module.exports?屬性），該對象只有在腳本運行完才會生成
• ES6 Module：模塊輸出的是一個值的引用，編譯時輸出接口，ES6模塊不是對象，它對外接口只是一種靜態(tài)定義，在代碼靜態(tài)解析階段就會生成。

#四、框架相關

#4.1 數(shù)據(jù)雙向綁定原理：常見數(shù)據(jù)綁定的方案

• Object.defineProperty（vue）：劫持數(shù)據(jù)的?getter?和?setter
• 臟值檢測（angularjs）：通過特定事件進行輪循 發(fā)布/訂閱模式：通過消息發(fā)布并將消息進行訂閱

#4.2 VDOM：三個 part

• 虛擬節(jié)點類，將真實?DOM節(jié)點用?js?對象的形式進行展示，并提供?render?方法，將虛擬節(jié)點渲染成真實?DOM
• 節(jié)點?diff?比較：對虛擬節(jié)點進行?js?層面的計算，并將不同的操作都記錄到?patch?對象
• re-render：解析?patch?對象，進行?re-render

補充1：VDOM 的必要性？

• 創(chuàng)建真實DOM的代價高：真實的?DOM?節(jié)點?node?實現(xiàn)的屬性很多，而?vnode?僅僅實現(xiàn)一些必要的屬性，相比起來，創(chuàng)建一個?vnode?的成本比較低。
• 觸發(fā)多次瀏覽器重繪及回流：使用?vnode?，相當于加了一個緩沖，讓一次數(shù)據(jù)變動所帶來的所有?node?變化，先在?vnode?中進行修改，然后?diff?之后對所有產(chǎn)生差異的節(jié)點集中一次對?DOM tree?進行修改，以減少瀏覽器的重繪及回流。

補充2：vue 為什么采用 vdom？

引入?Virtual DOM?在性能方面的考量僅僅是一方面。

• 性能受場景的影響是非常大的，不同的場景可能造成不同實現(xiàn)方案之間成倍的性能差距，所以依賴細粒度綁定及?Virtual DOM?哪個的性能更好還真不是一個容易下定論的問題。
• Vue?之所以引入了?Virtual DOM，更重要的原因是為了解耦?HTML依賴，這帶來兩個非常重要的好處是：

• 不再依賴?HTML?解析器進行模版解析，可以進行更多的?AOT?工作提高運行時效率：通過模版?AOT?編譯，Vue?的運行時體積可以進一步壓縮，運行時效率可以進一步提升；
• 可以渲染到?DOM?以外的平臺，實現(xiàn)?SSR、同構渲染這些高級特性，Weex等框架應用的就是這一特性。

綜上，Virtual DOM?在性能上的收益并不是最主要的，更重要的是它使得?Vue?具備了現(xiàn)代框架應有的高級特性。

#4.3 vue 和 react 區(qū)別

• 相同點：都支持?ssr，都有?vdom，組件化開發(fā)，實現(xiàn)?webComponents?規(guī)范，數(shù)據(jù)驅(qū)動等
• 不同點：vue?是雙向數(shù)據(jù)流（當然為了實現(xiàn)單數(shù)據(jù)流方便管理組件狀態(tài)，vuex?便出現(xiàn)了），react?是單向數(shù)據(jù)流。vue的?vdom?是追蹤每個組件的依賴關系，不會渲染整個組件樹，react?每當應該狀態(tài)被改變時，全部子組件都會?re-render

#4.4 為什么用 vue

簡潔、輕快、舒服

#五、網(wǎng)絡基礎類

#5.1 跨域

很多種方法，但萬變不離其宗，都是為了搞定同源策略。重用的有?jsonp、iframe、cors、img、HTML5 postMessage等等。其中用到?html?標簽進行跨域的原理就是?html?不受同源策略影響。但只是接受?Get?的請求方式，這個得清楚。

延伸1：img iframe script 來發(fā)送跨域請求有什么優(yōu)缺點？

1.?iframe

• 優(yōu)點：跨域完畢之后DOM操作和互相之間的JavaScript調(diào)用都是沒有問題的
• 缺點：1.若結果要以URL參數(shù)傳遞，這就意味著在結果數(shù)據(jù)量很大的時候需要分割傳遞，巨煩。2.還有一個是iframe本身帶來的，母頁面和iframe本身的交互本身就有安全性限制。

2. script

• 優(yōu)點：可以直接返回json格式的數(shù)據(jù)，方便處理
• 缺點：只接受GET請求方式

3. 圖片ping

• 優(yōu)點：可以訪問任何url，一般用來進行點擊追蹤，做頁面分析常用的方法
• 缺點：不能訪問響應文本，只能監(jiān)聽是否響應

延伸2：配合 webpack 進行反向代理？

webpack?在?devServer?選項里面提供了一個?proxy?的參數(shù)供開發(fā)人員進行反向代理

'/api': {target: 'http://www.example.com', // your target hostchangeOrigin: true, // needed for virtual hosted sitespathRewrite: {'^/api': '' // rewrite path} },

然后再配合?http-proxy-middleware?插件對?api?請求地址進行代理

const express = require('express'); const proxy = require('http-proxy-middleware'); // proxy api requests const exampleProxy = proxy(options); // 這里的 options 就是 webpack 里面的 proxy 選項對應的每個選項// mount `exampleProxy` in web server const app = express(); app.use('/api', exampleProxy); app.listen(3000);

然后再用?nginx?把允許跨域的源地址添加到報頭里面即可

說到?nginx?，可以再談談?CORS?配置，大致如下

location / {if ($request_method = 'OPTIONS') {add_header 'Access-Control-Allow-Origin' '*'; add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS'; add_header 'Access-Control-Allow-Credentials' 'true';add_header 'Access-Control-Allow-Headers' 'DNT, X-Mx-ReqToken, Keep-Alive, User-Agent, X-Requested-With, If-Modified-Since, Cache-Control, Content-Type'; add_header 'Access-Control-Max-Age' 86400; add_header 'Content-Type' 'text/plain charset=UTF-8'; add_header 'Content-Length' 0; return 200; } }

#5.2 http 無狀態(tài)無連接

• http?協(xié)議對于事務處理沒有記憶能力
• 對同一個url請求沒有上下文關系
• 每次的請求都是獨立的，它的執(zhí)行情況和結果與前面的請求和之后的請求是無直接關系的，它不會受前面的請求應答情況直接影響，也不會直接影響后面的請求應答情況
• 服務器中沒有保存客戶端的狀態(tài)，客戶端必須每次帶上自己的狀態(tài)去請求服務器
• 人生若只如初見，請求過的資源下一次會繼續(xù)進行請求

http協(xié)議無狀態(tài)中的 狀態(tài) 到底指的是什么？！

• 【狀態(tài)】的含義就是：客戶端和服務器在某次會話中產(chǎn)生的數(shù)據(jù)
• 那么對應的【無狀態(tài)】就意味著：這些數(shù)據(jù)不會被保留
• 通過增加cookie和session機制，現(xiàn)在的網(wǎng)絡請求其實是有狀態(tài)的
• 在沒有狀態(tài)的http協(xié)議下，服務器也一定會保留你每次網(wǎng)絡請求對數(shù)據(jù)的修改，但這跟保留每次訪問的數(shù)據(jù)是不一樣的，保留的只是會話產(chǎn)生的結果，而沒有保留會話

#5.3 http-cache：就是 http 緩存

1. 首先得明確 http 緩存的好處

• 減少了冗余的數(shù)據(jù)傳輸，減少網(wǎng)費
• 減少服務器端的壓力
• Web?緩存能夠減少延遲與網(wǎng)絡阻塞，進而減少顯示某個資源所用的時間
• 加快客戶端加載網(wǎng)頁的速度

2. 常見 http 緩存的類型

• 私有緩存（一般為本地瀏覽器緩存）
• 代理緩存

3. 然后談談本地緩存

本地緩存是指瀏覽器請求資源時命中了瀏覽器本地的緩存資源，瀏覽器并不會發(fā)送真正的請求給服務器了。它的執(zhí)行過程是

• 第一次瀏覽器發(fā)送請求給服務器時，此時瀏覽器還沒有本地緩存副本，服務器返回資源給瀏覽器，響應碼是200 OK，瀏覽器收到資源后，把資源和對應的響應頭一起緩存下來
• 第二次瀏覽器準備發(fā)送請求給服務器時候，瀏覽器會先檢查上一次服務端返回的響應頭信息中的Cache-Control，它的值是一個相對值，單位為秒，表示資源在客戶端緩存的最大有效期，過期時間為第一次請求的時間減去Cache-Control的值，過期時間跟當前的請求時間比較，如果本地緩存資源沒過期，那么命中緩存，不再請求服務器
• 如果沒有命中，瀏覽器就會把請求發(fā)送給服務器，進入緩存協(xié)商階段。

與本地緩存相關的頭有：Cache-Control、Expires，Cache-Control有多個可選值代表不同的意義，而Expires就是一個日期格式的絕對值。

3.1 Cache-Control

Cache-Control是HTPP緩存策略中最重要的頭，它是HTTP/1.1中出現(xiàn)的，它由如下幾個值

• no-cache：不使用本地緩存。需要使用緩存協(xié)商，先與服務器確認返回的響應是否被更改，如果之前的響應中存在ETag，那么請求的時候會與服務端驗證，如果資源未被更改，則可以避免重新下載
• no-store：直接禁止游覽器緩存數(shù)據(jù)，每次用戶請求該資源，都會向服務器發(fā)送一個請求，每次都會下載完整的資源
• public：可以被所有的用戶緩存，包括終端用戶和CDN等中間代理服務器。
• private：只能被終端用戶的瀏覽器緩存，不允許CDN等中繼緩存服務器對其緩存。
• max-age：從當前請求開始，允許獲取的響應被重用的最長時間（秒）。

# 例如：Cache-Control: public, max-age=1000 # 表示資源可以被所有用戶以及代理服務器緩存，最長時間為1000秒。

3.2 Expires

Expires是HTTP/1.0出現(xiàn)的頭信息，同樣是用于決定本地緩存策略的頭，它是一個絕對時間，時間格式是如Mon, 10 Jun 2015 21:31:12 GMT，只要發(fā)送請求時間是在Expires之前，那么本地緩存始終有效，否則就會去服務器發(fā)送請求獲取新的資源。如果同時出現(xiàn)Cache-Control：max-age和Expires，那么max-age優(yōu)先級更高。他們可以這樣組合使用

Cache-Control: public Expires: Wed, Jan 10 2018 00:27:04 GMT

3.3 所謂的緩存協(xié)商

當?shù)谝淮握埱髸r服務器返回的響應頭中存在以下情況時

• 沒有?Cache-Control?和?Expires
• Cache-Control?和?Expires?過期了
• Cache-Control?的屬性設置為?no-cache?時

那么瀏覽器第二次請求時就會與服務器進行協(xié)商，詢問瀏覽器中的緩存資源是不是舊版本，需不需要更新，此時，服務器就會做出判斷，如果緩存和服務端資源的最新版本是一致的，那么就無需再次下載該資源，服務端直接返回304 Not Modified?狀態(tài)碼，如果服務器發(fā)現(xiàn)瀏覽器中的緩存已經(jīng)是舊版本了，那么服務器就會把最新資源的完整內(nèi)容返回給瀏覽器，狀態(tài)碼就是200 Ok，那么服務端是根據(jù)什么來判斷瀏覽器的緩存是不是最新的呢？其實是根據(jù)HTTP的另外兩組頭信息，分別是：Last-Modified/If-Modified-Since?與?ETag/If-None-Match。

Last-Modified 與 If-Modified-Since

• 瀏覽器第一次請求資源時，服務器會把資源的最新修改時間Last-Modified:Thu, 29 Dec 2011 18:23:55 GMT放在響應頭中返回給瀏覽器
• 第二次請求時，瀏覽器就會把上一次服務器返回的修改時間放在請求頭If-Modified-Since:Thu, 29 Dec 2011 18:23:55發(fā)送給服務器，服務器就會拿這個時間跟服務器上的資源的最新修改時間進行對比

如果兩者相等或者大于服務器上的最新修改時間，那么表示瀏覽器的緩存是有效的，此時緩存會命中，服務器就不再返回內(nèi)容給瀏覽器了，同時Last-Modified頭也不會返回，因為資源沒被修改，返回了也沒什么意義。如果沒命中緩存則最新修改的資源連同Last-Modified頭一起返回

# 第一次請求返回的響應頭 Cache-Control:max-age=3600 Expires: Fri, Jan 12 2018 00:27:04 GMT Last-Modified: Wed, Jan 10 2018 00:27:04 GMT # 第二次請求的請求頭信息 If-Modified-Since: Wed, Jan 10 2018 00:27:04 GMT

這組頭信息是基于資源的修改時間來判斷資源有沒有更新，另一種方式就是根據(jù)資源的內(nèi)容來判斷，就是接下來要討論的?ETag?與?If-None-Match

ETag與If-None-Match

ETag/If-None-Match與Last-Modified/If-Modified-Since的流程其實是類似的，唯一的區(qū)別是它基于資源的內(nèi)容的摘要信息（比如MD5 hash）來判斷

瀏覽器發(fā)送第二次請求時，會把第一次的響應頭信息ETag的值放在If-None-Match的請求頭中發(fā)送到服務器，與最新的資源的摘要信息對比，如果相等，取瀏覽器緩存，否則內(nèi)容有更新，最新的資源連同最新的摘要信息返回。用ETag的好處是如果因為某種原因到時資源的修改時間沒改變，那么用ETag就能區(qū)分資源是不是有被更新。

# 第一次請求返回的響應頭：Cache-Control: public, max-age=31536000 ETag: "15f0fff99ed5aae4edffdd6496d7131f" # 第二次請求的請求頭信息：If-None-Match: "15f0fff99ed5aae4edffdd6496d7131f"

#5.4 cookie 和 session

• session： 是一個抽象概念，開發(fā)者為了實現(xiàn)中斷和繼續(xù)等操作，將?user agent和?server?之間一對一的交互，抽象為“會話”，進而衍生出“會話狀態(tài)”，也就是?session?的概念
• cookie：它是一個世紀存在的東西，http?協(xié)議中定義在?header?中的字段，可以認為是?session?的一種后端無狀態(tài)實現(xiàn)

現(xiàn)在我們常說的?session，是為了繞開?cookie?的各種限制，通常借助?cookie本身和后端存儲實現(xiàn)的，一種更高級的會話狀態(tài)實現(xiàn)

session?的常見實現(xiàn)要借助cookie來發(fā)送?sessionID

#5.5 安全問題，如 XSS 和 CSRF

• XSS：跨站腳本攻擊，是一種網(wǎng)站應用程序的安全漏洞攻擊，是代碼注入的一種。常見方式是將惡意代碼注入合法代碼里隱藏起來，再誘發(fā)惡意代碼，從而進行各種各樣的非法活動

防范：記住一點 “所有用戶輸入都是不可信的”，所以得做輸入過濾和轉(zhuǎn)義

• CSRF：跨站請求偽造，也稱?XSRF，是一種挾制用戶在當前已登錄的Web應用程序上執(zhí)行非本意的操作的攻擊方法。與?XSS?相比，XSS利用的是用戶對指定網(wǎng)站的信任，CSRF利用的是網(wǎng)站對用戶網(wǎng)頁瀏覽器的信任。

防范：用戶操作驗證（驗證碼），額外驗證機制（token使用）等

總結

以上是生活随笔為你收集整理的前端面试-精简版的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。