記一次前端面試的全過程
接上一篇面試總結ofollow,noindex">一年半經驗，百度、有贊、阿里面試總結 ，把這段時間的面試總結結束一下吧。
本文主要記錄一下當天面試的全過程（可能有遺漏，事隔三四天了，我已經儘量回憶了），答案亦為參考答案，僅供借鑑。
正文
有贊一面結束後過了兩天就收到了二面的邀請，我回復面試邀請的簡訊，說最近可能請假太多，能不能約到晚上面試，對方很很爽快的答應了，就約在了晚上七點半，我回復可以的，然後第二天，收到了確切的面試的時間和地點，時間定在了晚上7點15分。
到了面試當天，我提前了五分鐘下班，照著百度地圖的提示路線（約1小時9分鐘），到了公交站等車。。。然後等呀等，等了十五分鐘公交還沒來，怕自己遲到，就打了個滴滴過去，到了面試地點之後上到了公司的前臺，前臺沒有人，可能是因為到飯點了，前臺去吃飯了吧。然後看到前臺那層樓好多人在打乒乓球，大家也玩得挺開心，看起來環境也很不錯，當時想，誒呀，原來有讚的環境這麼好。等了一會兒之後，看了一下簡訊，發現面試邀請裡留有面試官的聯絡電話，果斷打了過去，過了一會兒面試官到前臺接我，然後找了一個會議室，開始了當天的面試。
面試官：先自我介紹吧
我：巴拉巴拉...
面試官：先說一下你上一家公司的研發部署流程
我：巴拉巴拉...(其實這個是我絕活，每次都可以吹很久)
面試官：既然你們是檔案覆蓋式釋出，那你們的快取是怎麼重新整理的
我：從公司的業務出發，巴拉巴拉...（還沒說完）
面試官：那我現在就不談業務，你說一下瀏覽器的快取方案吧
我：哦，脫離業務呀，首先，瀏覽器有兩種快取方案，一種是強快取一種是協商快取。
面試官：嗯，那怎麼使用強快取？
我：瀏覽器在第一次請求資源的時候，服務端響應頭裡可以設定expires
欄位，該欄位表示該資源的快取過期時間，第二次請求的時候，如果時間還在該快取時間之內，則會直接使用快取，否則重新載入資源，這個expires
欄位有個缺陷，就是它必須服務端和客戶端的時間嚴格同步才能生效，所以現在很多人不會使用改方案。另外一種方案是第一次請求資源的時候，服務端設定響應頭cache-control: max-age
，這樣設定的意思是告訴瀏覽器，這個資源什麼時候過期，等第二次請求資源的時候，判斷是否超出了過期時間，如果沒超出，直接使用快取。
面試官：cache-control這個頭是服務端設定的還是客戶端設定的？
我：cache-control服務端設定的
面試官：cache-control的其他值，你也說一下吧
我：首先是public，客戶端和服務端都可以快取；然後是private，只能客戶端快取；no-store，不使用快取；no-cache，使用協商快取。
面試官：那你往下說，說一下協商快取
我：協商快取有兩種，一種是Last-Modified，就是第一次請求資源的時候，服務端會在響應頭裡面設定該欄位，表示該資源的最後修改時間，瀏覽器第二次請求該資源的時候，會在請求頭裡面加上一個欄位If-Modified-Since，值為第一次請求的時候服務端返回的Last-Modified的值，服務端會判斷資源當時的最後更改時間與請求頭裡面的If-Modified-Since欄位是否相同，如果相同，則告訴客戶端使用快取，否則重新下載資源。然後另外一種協商快取時使用ETag，原理與Last-Modified類似，就是第一次請求的時候，服務端會根據資源的內容或者最後修改時間生成一個標識，然後在響應頭裡面設定為ETag返回給客戶端，客戶端第二次請求的時候會在請求頭裡面帶上這個ETag，也就是在請求頭裡面加上If-None-Match欄位，服務端接收到了ETag之後判斷是否與原來第一次的標識相同，如果相同，則告訴客戶端使用快取。
說一下Last-modified/If-Modified-Since和If-None-Match/ETag兩種方案的優缺點
我：嗯呢，這個我想一想（我並不知道，假裝思考一下）......我覺得其實ETag其實也是有的時候是根據資源的最後修改時間生成的，原理和Last-modified好像有點類似，而ETag需要耗費服務端的資源去生成，所以效能較低。。。（雖然不會，也儘量說說，萬一面試官也不知道呢。哈哈哈哈）
面試官：那說一下效能優化的方案吧
我：首先，減少HTTP請求次數，比如說合並CSS和JS檔案，但是也不要完全的合併在同一個檔案裡面，一個域名分散三四個資源，這樣方便瀏覽器去並行下載，當然瀏覽器對每個域名的並行下載個數有限制，一個域名分配三四個資源雖然增加了HTTP請求數量，但是對比並行下載來說，價效比更高。
面試官：為什麼瀏覽器要限制同一域名並行下載資源的個數。
我：嗯呢，這個我也想一下（其實我也不知道）......這個我沒有深究過，難道是因為瀏覽器啟動了太多下載執行緒的原因？
面試官：下載資源和執行緒有什麼關係？
我：除了了每個標籤頁是一個程序以外，瀏覽器有一個程序是專門用來管理下載，我覺得大概是每下載一個資源啟動一個執行緒吧（反正我也不知道，也猜猜結果是不是這樣）
面試官：（沉默了一會兒），程序和執行緒區別是什麼
我：程序是分配記憶體的最小單位，執行緒是CPU排程的最小單位，程序可以包含多個執行緒。
面試官：nodejs用得多嗎？說一下nodejs程序之間是怎麼通訊的
我：nodejs用的比較少，nodejs可以啟動子執行緒，然後用主執行緒來監聽訂閱子執行緒的訊息，子執行緒之間的通訊，由主執行緒來控制。（大概錯了吧，應該是程序）
面試官：好吧，效能優化繼續往下說
我：減少HTTP請求數量還可以把圖示合併在同一張圖片裡面，使用的時候用background-position去控制。然後首屏的時候圖片使用懶載入的形式，儘量在需要顯示的時候在載入它，當然佔位符和圖片儘量指定寬度和高度，避免圖片載入完之後替換圖片瀏覽器會進行迴流。
面試官：圖片懶載入怎麼實現
我：監聽瀏覽器的滾動事件，結合clientHeight、offsetHeight、scrollTop、scrollHeight等等變數計算當前圖片是否在可視區域，如果在，則替換src載入圖片，當然這個滾動事件要主要節流。
面試官：怎麼判斷圖片是否載入完成
我：使用onload事件。
面試官：好吧，你繼續往下說。
我：效能優化的話，還可以合理的利用快取，儘量把CSS和JS檔案使用外鏈的形式，雖然使用內聯的CSS和JS在空快取的時候更快，因為內聯的樣式和指令碼不需要傳送HTTP請求，但是為了儘量發揮瀏覽器的快取功能，儘量使用外鍊形式。
我：然後儘量把CSS放在頭部，JS放在底部。
面試官：假如現在頁面裡放在head的css檔案下載速度很慢，頁面會出現什麼情況？
我：大概頁面會等待這個CSS的下載，這個時候頁面是白屏狀態，然後這個CSS資源會有一個超時時間，假如超過了這個超時時間，這個資源相當於會下載失敗，瀏覽器會直接跳過這個CSS資源，根據已有的CSS資源生成CSS規則樹，進而生成Render樹，然後渲染頁面。
面試官：假如我現在在頁面動態添加了一個CSS檔案，頁面一定會迴流嗎？
我：只要假如的CSS影響到了頁面的結構，那麼瀏覽器就會迴流。
面試官：例如頁面這個CSS檔案中有translate3d呢？
我：其實我感覺它不會迴流，因為translate3d只是變換了自己的位置，不會影響其他元素的位置，但是實際上是會造成迴流的。
面試官：那假如我在頁面裡面加了一個
我：不會，因為沒有影響頁面結構的變化。
面試官：好吧，那你繼續往下說
我：效能優化，儘量使用CDN。
面試官：CDN的原理是啥？
我：首先，瀏覽器會先請求CDN域名，CDN域名伺服器會給瀏覽器返回指定域名的CNAME，瀏覽器在對這些CNAME進行解析，得到CDN快取伺服器的IP地址，瀏覽器在去請求快取伺服器，CDN快取伺服器根據內部專用的DNS解析得到實際IP，然後快取伺服器會向實際IP地址請求資源，快取伺服器得到資源後進行本地儲存和返回給瀏覽器客戶端。
面試官：你來實現以下剛剛說的節流函式吧
。。。當時有點不記得什麼是防抖，什麼節流，把函式寫成了防抖。（這個時候有一個人走進了會議室，好像是一面小哥）
var debounce = function(fn, delay, context) {
let timer = null;
return function() {
if (timer) {
clearTimeout(timer);
}
timer = setTimeout(() => {
const arg = Array.prototype.slice.call(arguments);
fn.apply(context, arg);
}, delay)
}
}
// 測試部分
var run = function(text) {
console.log(text);
}
run = debounce(run, 200);
run('run1');
run('run2');
setTimeout(() => {
run('run3');
}, 201)
複製程式碼
面試官：我這邊沒有什麼問題了，你還有什麼要補充的嗎？
我：那我把效能優化這個問題說完？
面試官：可以。
然後我開始描述使用webpack使用進行減少js檔案的體積，可以使用babel-plugin-import、babel-plugin-component、webpack.ContextReplacementPlugin、webpack.IgnorePlugin...
面試官：這個我知道。你還有什麼問題嗎？（大概是想結束面試了吧，不想讓我往下說了）
我：巴拉巴拉。。。問了很多關於有贊公司的問題，比如公司有多少層樓啊、公司主要技術棧啊、公司主要做2B還是2C的啊，公司有多少前端的啊（本人可能還是太囉嗦）
最後問了一個問題，問了一下面試官本次便是的評價是啥，面試官只回了一句，還好吧。然後面試到此結束了，全稱大概一個多小時。
面試結束後，面試官送我到電梯口。。。可以說樓層是真的高，上樓和下樓都需要等很久的電梯。。。到了外面之後，下著大雨，落湯雞似的又打了個滴滴回家，結束了當天的面試之旅。
最後
直到昨天，收到了有讚的面試結果回覆郵件，告知沒有合適的職位（有贊還是挺不錯的，沒通過面試還通知一下），心裡雖然有點不甘，但是想想確實可能是自己不夠優秀，或者是自己面得不是很好，或者是自己的能力跟公司的職位不太匹配。
在上一篇面試總結中一年半經驗，百度、有贊、阿里面試總結 ，部分同學關心最後面試結果情況，情況是已經有幸的收到了百度的offer，螞蟻金服的一面面試已經過一週了，不知道是因為流程太長還是一面被掛了。
這個時候一想，其實面試還是有很大的運氣成分在裡面，正好公司需要，正好你又合適，這個時候就很幸運。