摘要：的回調(diào)函數(shù)執(zhí)行的優(yōu)先級(jí)要高于，屬于觀察者。的回調(diào)函數(shù)保存在一個(gè)數(shù)組中，會(huì)將異步回調(diào)放到當(dāng)前幀的末尾回調(diào)之前，如果過多，會(huì)導(dǎo)致回調(diào)不斷延后最后堆積太多。

阿里一面是電話面，問得不多，但是挺有深度。面試官一開始就說，看了你的項(xiàng)目，覺得你基礎(chǔ)挺好的，那我就不問基礎(chǔ)了。然后全程就真的沒有問一個(gè)基礎(chǔ)問題。。

我首先想到了滾動(dòng)條位置無法還原的問題，也就是點(diǎn)擊列表項(xiàng)跳到詳情頁后再返回時(shí)，滾動(dòng)條位置無法還原的bug。我的解決辦法是通過vuex來保存每個(gè)組件里的滾動(dòng)條的位置，然后返回時(shí)再滾動(dòng)到這個(gè)位置即可，不過得設(shè)置滾動(dòng)時(shí)間為0，不然會(huì)有明顯的滾動(dòng)過程，用戶體驗(yàn)會(huì)很差。
然后又想到了做IP定位時(shí)遇到的后臺(tái)express服務(wù)端無法獲取用戶真實(shí)ip地址的問題。其實(shí)express是可以獲取用戶真實(shí)ip地址的，只是我的nginx沒有寫好配置，導(dǎo)致express獲取到的始終是127.0.0.1本地ip地址。無論怎么獲取，都是這個(gè)地址。
解決辦法是修改nginx的配置文件：

location / {
   proxy_pass http://localhost:8080;   # 項(xiàng)目真實(shí)地址
　 proxy_set_header Host $host;
   proxy_set_header X-Real-IP $remote_addr;
   proxy_set_header REMOTE-HOST $remote_addr;
   proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

重啟nginx： ./nginx -s reload 即可。
然后在express服務(wù)端里，通過 req.headers[‘x-real-ip’]即可拿到真實(shí)ip地址。然后就可以根據(jù)這個(gè)ip地址，通過淘寶ip地址庫，定位到用戶的地理位置了。
QQ項(xiàng)目地址：https://github.com/lensh/vue-qq （支持實(shí)時(shí)群聊、實(shí)時(shí)私聊、特別關(guān)心、屏蔽聊天、IP地位、實(shí)時(shí)氣溫顯示等QQ核心功能）

還好之前對(duì)底層還是有所了解，看過源碼以及一些博客，所以基本答了出來。
Angular的實(shí)現(xiàn)： AngularJS 采用“臟值檢測”的方式，數(shù)據(jù)發(fā)生變更后，對(duì)于所有的數(shù)據(jù)和視圖的綁定關(guān)系進(jìn)行一次檢測，識(shí)別是否有數(shù)據(jù)發(fā)生了改變，有變化進(jìn)行處理，可能進(jìn)一步引發(fā)其他數(shù)據(jù)的改變，所以這個(gè)過程可能會(huì)循環(huán)幾次，一直到不再有數(shù)據(jù)變化發(fā)生后，將變更的數(shù)據(jù)發(fā)送到視圖，更新頁面展現(xiàn)。
只有當(dāng)改變$scope的值、使用內(nèi)置的$interval、$timeout的時(shí)候，才會(huì)進(jìn)行“臟檢測”。
如果是手動(dòng)對(duì) ViewModel 的數(shù)據(jù)進(jìn)行變更，為確保變更同步到視圖，需要手動(dòng)觸發(fā)一次“臟值檢測”。
Vue的實(shí)現(xiàn)：核心就是數(shù)據(jù)劫持+發(fā)布/訂閱模式，VueJS 使用 ES5 提供的 Object.defineProperty() 方法，監(jiān)控對(duì)數(shù)據(jù)的操作，從而可以自動(dòng)觸發(fā)數(shù)據(jù)同步。并且，由于是在不同的數(shù)據(jù)上觸發(fā)同步，可以精確的將變更發(fā)送給綁定的視圖，而不是對(duì)所有的數(shù)據(jù)都執(zhí)行一次檢測。
具體實(shí)現(xiàn)可參考 https://github.com/lensh/mvvm 。

很多方法：異步加載模塊（代碼分割）；提取第三方庫（使用cdn或者vender）；代碼壓縮；去除不必要的插件；去除devtool選項(xiàng)等等。

避免方法也很多：簡單限定爬蟲的最大循環(huán)次數(shù)，對(duì)于某web站點(diǎn)訪問超過一定閾值就跳出，避免無限循環(huán)。保存一個(gè)已訪問url列表，記錄頁面是否被訪問過的技術(shù)。廣度優(yōu)先的爬行，避免深度優(yōu)先陷入某個(gè)站點(diǎn)的環(huán)路中，無法訪問其他站點(diǎn)。

使用PureRenderMixin、shouldComponentUpdate來避免不必要的虛擬DOM diff，在render內(nèi)部優(yōu)化虛擬DOM的diff速度，以及讓diff結(jié)果最小化。使用immutable.js解決復(fù)雜數(shù)據(jù)diff、clone等問題。
immutable.js實(shí)現(xiàn)原理：持久化數(shù)據(jù)結(jié)構(gòu)，也就是使用舊數(shù)據(jù)創(chuàng)建新數(shù)據(jù)時(shí)，要保證舊數(shù)據(jù)同時(shí)可用且不變。同時(shí)為了避免 deepCopy 把所有節(jié)點(diǎn)都復(fù)制一遍帶來的性能損耗，Immutable 使用了結(jié)構(gòu)共享，即如果對(duì)象樹中一個(gè)節(jié)點(diǎn)發(fā)生變化，只修改這個(gè)節(jié)點(diǎn)和受它影響的父節(jié)點(diǎn)，其它節(jié)點(diǎn)則進(jìn)行共享。

明顯是處理異步操作的啊，前者是讓Redux的dispatch方法的參數(shù)支持promise，后者是支持函數(shù)，而且還是一個(gè)異步函數(shù)。異步函數(shù)里面要dispatch兩次，分別表示異步請(qǐng)求開始和異步請(qǐng)求完成。

configurable和enumerable的作用？configurable設(shè)置為true后還能刪除該屬性嗎？
之前研究過這個(gè)，所以就很容易地回答了出來。該函數(shù)返回指定對(duì)象（參數(shù)）的所有自身屬性描述符。所謂自身屬性描述符就是在對(duì)象自身內(nèi)定義，不是通過原型鏈繼承來的屬性。
屬性描述符：configurable、enumerable、value、writable、get、set。
configurable：當(dāng)該值為true時(shí)，該屬性描述符才能夠被改變，同時(shí)該屬性也能從對(duì)應(yīng)的對(duì)象上被刪除。默認(rèn)為 false。
enumerable：當(dāng)且僅當(dāng)該屬性的 enumerable 為 true時(shí)，該屬性才能夠出現(xiàn)在對(duì)象的枚舉屬性中。默認(rèn)為 false。

Promise.all 把多個(gè)promise實(shí)例當(dāng)成一個(gè)promise實(shí)例,當(dāng)這些實(shí)例的狀態(tài)都發(fā)生改變時(shí)才會(huì)返回一個(gè)新的promise實(shí)例，才會(huì)執(zhí)行then方法。
Promise.race 只要該數(shù)組中的 Promise 對(duì)象的狀態(tài)發(fā)生變化（無論是resolve還是reject）該方法都會(huì)返回。

利用錨點(diǎn)結(jié)合CSS的target偽類就可以了。

首先一個(gè)區(qū)別是安裝它們的Apache Web服務(wù)器版本的差異。Apache 1.x系列沒有內(nèi)建網(wǎng)頁壓縮技術(shù)，所以才去用額外的第三方mod_gzip 模塊來執(zhí)行壓縮。而Apache 2.x官方在開發(fā)的時(shí)候，就把網(wǎng)頁壓縮考慮進(jìn)去，內(nèi)建了mod_deflate 這個(gè)模塊，用以取代mod_gzip。雖然兩者都是使用的Gzip壓縮算法，它們的運(yùn)作原理是類似的。
第二個(gè)區(qū)別是壓縮質(zhì)量。mod_deflate 壓縮速度略快而mod_gzip 的壓縮比略高。一般默認(rèn)情況下，mod_gzip 會(huì)比mod_deflate 多出4%~6％的壓縮量。
第三個(gè)區(qū)別是對(duì)服務(wù)器資源的占用。 一般來說mod_gzip 對(duì)服務(wù)器CPU的占用要高一些。mod_deflate 是專門為確保服務(wù)器的性能而使用的一個(gè)壓縮模塊，mod_deflate 需要較少的資源來壓縮文件。這意味著在高流量的服務(wù)器，使用mod_deflate 可能會(huì)比mod_gzip 加載速度更快。

spawn函數(shù)用給定的命令發(fā)布一個(gè)子進(jìn)程，只能運(yùn)行指定的程序，參數(shù)需要在列表中給出。
exec也是一個(gè)創(chuàng)建子進(jìn)程的函數(shù)，與spawn函數(shù)不同它可以直接接受一個(gè)回調(diào)函數(shù)作為參數(shù)，回調(diào)函數(shù)有三個(gè)參數(shù)，分別是err, stdout , stderr。
execFile函數(shù)與exec函數(shù)類似，但execFile函數(shù)更顯得精簡，因?yàn)樗梢灾苯訄?zhí)行所指定的文件。
fork函數(shù)可直接運(yùn)行Node.js模塊，我們可以直接通過指定模塊路徑而直接進(jìn)行操作。

process.nextTick()的回調(diào)函數(shù)執(zhí)行的優(yōu)先級(jí)要高于setImmediate()，process.nextTick()屬于idle觀察者。
setImmediate()屬check觀察者.在每一輪循環(huán)檢查中,idle觀察者先于I/O觀察者,I/O觀察者先于check觀察者。
process.nextTick()的回調(diào)函數(shù)保存在一個(gè)數(shù)組中，會(huì)將異步回調(diào)放到當(dāng)前幀的末尾、io回調(diào)之前，如果nextTick過多，會(huì)導(dǎo)致io回調(diào)不斷延后,最后callback堆積太多。
setImmediate()的結(jié)果則是保存在鏈表中，會(huì)將異步回調(diào)放到下一幀,不影響io回調(diào),不會(huì)造成callback 堆積。
process.nextTick()在每輪循環(huán)中會(huì)將數(shù)組中的回調(diào)函數(shù)全部執(zhí)行完，而setImmediate()在每輪循環(huán)中執(zhí)行鏈表中的一個(gè)回調(diào)函數(shù)。
process.nextTick()，效率最高，消費(fèi)資源小，但會(huì)阻塞CPU的后續(xù)調(diào)用；
setTimeout()，精確度不高，可能有延遲執(zhí)行的情況發(fā)生，且因?yàn)閯?dòng)用了紅黑樹，所以消耗資源大；
setImmediate()，消耗的資源小，也不會(huì)造成阻塞，但效率也是最低的。

（1）異步流程控制
Express 采用 callback 來處理異步，Koa v1 采用 generator，Koa v2 采用 async/await。
generator 和 async/await 使用同步的寫法來處理異步，明顯好于 callback 和 promise，async/await 在語義化上又要比 generator 更強(qiáng)。
（2）錯(cuò)誤處理
Express 使用 callback 捕獲異常，對(duì)于深層次的異常捕獲不了，Koa 使用 try catch，能更好地解決異常捕獲。

[…new Set([1,2,3,1,’a’,1,’a’])]

當(dāng)時(shí)大概地講了一下意思，不過沒答完全。后了又復(fù)習(xí)了下：
（1）采用二進(jìn)制格式傳輸數(shù)據(jù)，而非 http1.1 的文本格式，二進(jìn)制格式在協(xié)議的解析和優(yōu)化擴(kuò)展上帶來更多的優(yōu)勢(shì)和可能
（2）對(duì)消息頭采用 HPACK 進(jìn)行壓縮傳輸，能夠節(jié)省消息頭占用的網(wǎng)絡(luò)的流量，而 http1.1 每次請(qǐng)求，都會(huì)攜帶大量冗余頭信息，浪費(fèi)了很多帶寬資源，頭壓縮能夠很好的解決該問題
（3）多路復(fù)用，就是多個(gè)請(qǐng)求都是通過一個(gè) TCP 連接并發(fā)完成，http1.1 雖然通過pipeline也能并發(fā)請(qǐng)求，但是多個(gè)請(qǐng)求之間的響應(yīng)會(huì)被阻塞的，所以 pipeline 至今也沒有被普及應(yīng)用，而 http2.0做到了真正的并發(fā)請(qǐng)求，同時(shí)，流還支持優(yōu)先級(jí)和流量控制
（4）Server Push，服務(wù)端能夠更快的把資源推送給客戶端，例如服務(wù)端可以主動(dòng)把 JS 和 CSS 文件推送給客戶端，而不需要客戶端解析 HTML再發(fā)送這些請(qǐng)求，當(dāng)客戶端需要的時(shí)候，它已經(jīng)在客戶端了。

當(dāng)時(shí)觸發(fā)條件只答出了1、2、4、5，而且4只說了inline-block。這種很多情況的一時(shí)半會(huì)確實(shí)很難答完全。。
完整答案：
BFC（塊級(jí)格式化上下文），是頁面上的一個(gè)隔離的獨(dú)立容器，容器里面的子元素不會(huì)影響到外面元素，反之亦然。它與普通的塊框類似，但不同之處在于:
（1）可以阻止元素被浮動(dòng)元素覆蓋。
（2）可以包含浮動(dòng)元素。
（3）可以阻止margin重疊。
滿足下列條件之一就可觸發(fā)BFC：
【1】根元素，即HTML元素
【2】float的值不為none
【3】overflow的值不為visible
【4】display的值為inline-block、table-cell、table-caption
【5】position的值為absolute或fixed

有了Last-Modified，為什么還要用ETag？
（1）因?yàn)槿绻谝幻腌娭畠?nèi)對(duì)一個(gè)文件進(jìn)行兩次更改，Last-Modified就會(huì)不正確。
（2）某些服務(wù)器不能精確的得到文件的最后修改時(shí)間。
（3）一些文件也許會(huì)周期性的更改，但是他的內(nèi)容并不改變(僅僅改變的修改時(shí)間)，這個(gè)時(shí)候我們并不希望客戶端認(rèn)為這個(gè)文件被修改了，而重新GET。

有了Etag，為什么還要用Last-Modified？
因?yàn)橛行r(shí)候 ETag 可以彌補(bǔ) Last-Modified 判斷的缺陷，但是也有時(shí)候 Last-Modified 可以彌補(bǔ) ETag 判斷的缺陷，比如一些圖片等靜態(tài)文件的修改，如果每次掃描內(nèi)容生成 ETag 來比較，顯然要比直接比較修改時(shí)間慢很多。所有說這兩種判斷是相輔相成的。

ETag的值服務(wù)端是對(duì)文件的索引節(jié)，大小和最后修改時(shí)間進(jìn)行Hash后得到的。

大概就只記得問了這些，大部分都回答了出來。當(dāng)然回答時(shí)還扯了一些其它的，就不說了。總體來說還是挺有深度的，日后還得繼續(xù)努力。
最后，我的github:https://github.com/lensh