2020.10.29騰訊QQ音樂社招前端電話一面總結
面試官晚上19:16打過來的，聊了44分鐘，到八點準時結束，無論過沒過，都記錄一下面試程序吧，是問了幾個大問題，在幾個大問題的基礎上根據你的回答，再去問一些小問題，
前言
【面試官】：先自我介紹下吧
【我】：我現在是在南京作業，作業一年多了，公司里用的是React框架，接下來我也打算以React為主技術堆疊，
【面試官】：嗯，沒了嗎
【我】：嗯…
【面試官】：你換作業的原因是什么
【我】：我是從大三開始就想進大廠了，一直也在準備著，畢業時投了一些簡歷但是沒有機會，所以又邊作業邊準備了一年多，現在有人幫我內推我就趕緊試一試，
【面試官】：你是什么開始學習前端的
【我】：我大三的時候開始在國外的一個叫做FCC(FreeCodeCamp.org)的網站上學習的，在那上面學了HTML、CSS、JQuery、JS，我在畢業的時候還不會框架，在學校里的時候，做專案都是用PHP+JQuery做的，進入這家公司之后，公司用的是React框架，我就花了一段時間感覺學習了React框架，學完React后感覺自己提升了好多，又接著學了一些前端的其他東西，前端的知識簡直越學越多，感覺都學不完
【面試官】：你是在一個網站上學習的，那你有沒有看過一些書籍之類的
【我】：我不怎么看紙質的書，我一般都是看網上的檔案，因為紙質的書代碼都在書上面，一行一行照著寫也很麻煩，而且不方便在我有疑問的時候得到反饋，我學習主要是以在網上買視頻課為主，因為買視頻課可以直接學習到這個技術怎么用，它的原理是什么，遇到不會的地方還可以去聯系他問他，現在這些付費的課程都會有個交流群，群里的其他學員也都會跟你一起交流，我覺得這樣學習效率高一點，比看書好一點，
(巴拉巴拉說了這么一大堆，面試官就直接進入正題開始問了)
有了解怎么給一個不存在的元素添加事件嗎
【我】：不存在的元素啊？那要先創建這個元素吧
【面試官】：那在創建之前就沒有辦法系結事件嗎
【我】：創建之前啊，那在創建之前…我好像不知道…
【面試官】：有一個div，里面會有一些元素，在點擊元素的時候會觸發一個事件，但是它現在并不在div里面
【我】：那可以把事件掛在父組件上面嗎，可以吧，由父組件觸發，然后可以檢測到里面的target是誰
【面試官】：那它利用的是什么原理
【我】：是事件的代理
【面試官】：事件的代理是什么原理
【我】：事件的冒泡
【面試官】：事件的三個階段是怎樣實作的
【我】：先是從父組件到子組件的捕獲，然后觸發事件，最后從子組件冒泡到父組件，
【面試官】：那用事件捕獲可以實作事件代理嗎
【我】：額…可以
【面試官】：那一般你是用什么方式實作的
【我】：我一般使用冒泡
【面試官】：那為什么不用捕獲呢
【我】：因為…嗯…嗯…我沒注意過這個
參考MDN：
對事件冒泡和捕捉的解釋
當一個事件發生在具有父元素的元素上(例如，在我們的例子中是<video>元素)時，現代瀏覽器運行兩個不同的階段 - 捕獲階段和冒泡階段， 在捕獲階段：瀏覽器檢查元素的最外層祖先
<html>，是否在捕獲階段中注冊了一個onclick事件處理程式，如果是，則運行它，然后，它移動到
<html>中單擊元素的下一個祖先元素，并執行相同的操作，然后是單擊元素再下一個祖先元素，依此類推，直到到達實際點擊的元素，在冒泡階段，恰恰相反:
瀏覽器檢查實際點擊的元素是否在冒泡階段中注冊了一個onclick事件處理程式，如果是，則運行它
然后它移動到下一個直接的祖先元素，并做同樣的事情，然后是下一個，等等，直到它到達
<html>元素，在現代瀏覽器中，默認情況下，所有事件處理程式都在冒泡階段進行注冊，
事件冒泡是令人討厭的行為，但有一種方法來解決它，標準事件物件具有可用的名為 stopPropagation()的函式, 當在事件物件上呼叫該函式時，它只會讓當前事件處理程式運行，但事件不會在冒泡鏈上進一步擴大，因此將不會有更多事件處理器被運行(不會向上冒泡)，
事件分三個階段：捕獲、目標、冒泡，
捕獲：由外向內，由不具體到最具體，由document到元素
目標：就是事件觸發的元素
冒泡：由內向外，由最具體到最不具體，由元素到document
事件委托
冒泡還允許我們利用事件委托——這個概念依賴于這樣一個事實,如果你想要在大量子元素中單擊任何一個都可以運行一段代碼，您可以將事件監聽器設定在其父節點上，并讓子節點上發生的事件冒泡到父節點上，而不是每個子節點單獨設定事件監聽器，
有了解過DOMContentLoaded這個事件嗎
【我】：知道，這個是在網頁圖片、CSS全部加載完之后觸發
【面試官】：window.onload事件呢？
【我】：啊，那你剛才問的是哪個，不是load嗎（原諒我耳背了…）
【面試官】：DOMContentLoaded，我剛才問的是DOMContentLoaded
【我】：哦抱歉那我剛才聽錯了，我剛才講的就是load事件，DOMContentLoaded事件就網頁的骨架加載完就觸發，不會等待圖片、CSS樣式加載完
【面試官】：那如果外鏈的JS沒有加載完，DOMContentLoaded事件會不會觸發？
【我】：不會，哦不，外鏈…它會觸發吧…我不太確定了
【面試官】：如果有個外鏈標簽在網頁的頭部，那網頁會展示內容嗎
【我】：是指script標簽嗎，還是指link啊？
【面試官】：外鏈的JS
【我】：那就渲染不出來了，JS會阻塞渲染
【面試官】：那DOMContentLoaded觸發以后，頁面上會展示內容嗎
【我】：會展示
【面試官】：那外連接沒加載完，DOMContentLoaded會觸發嗎
【我】：哦那不會，JS會阻止這個渲染行程
【面試官】：那在中間呢
【我】：在中間的話，那也不會
【面試官】那在尾部呢
【我】：不會，要等JS走完
【面試官】：那要想讓它不要阻塞的話，有什么辦法
【我】：可以給script標簽加一個defer屬性，還有async，讓它延遲加載
【面試官】：如果不用這兩個的話，還有什么其他方案
【我】：嗯…還有type=“module”
【面試官】：對于瀏覽器不支持的情況，比如這三個都不支持的情況，怎么實作呢
【我】：那可以把script標簽的加載寫在DOMContentLoaded事件的回呼中，執行的時候再去生成這個script標簽
【面試官】：嗯，那你這樣的話不就導致加載事件被延后了嗎，為什么要在這個事件中寫呢
【我】：因為這個時候頁面應該渲染好了吧，沒渲染好的話，會不會造成頁面的時間很長呢（此時我崩潰的內心：抱歉這一塊我不熟，我都是在亂說，我也不知道遇到外鏈加載是怎樣的程序，我好困，我只想睡覺，不要再引導我了，這個問題我答不上來的😭😭）
【面試官】：如果你用標簽加載的話，也會導致白屏嗎
【我】：會，會
【面試官】：你說的動態創建script標簽也會嗎
【我】：這個時候頁面已經大致加載完成了，只有圖片之類的沒加載完，創建script標簽用戶已經感知不到了，不會有白屏
【面試官】：我的意思是，不在這個事件里去回呼，直接通過動態創建script標簽的方式去加載，會不會阻塞
【我】：額…不會，直接寫在最尾部是吧
【面試官】：寫在頭部
【我】：啊，寫在頭部啊，寫在頭部的話，會
【面試官】：用動態創建標簽的方式也會是嗎
【我】：動態創建，就是創建到頭部去是嗎，…, …, 應該不會(我已麻木的內心：為什么一直揪著這個問題不放😭，我什么都不知道😭，我好困😭我已經聽不懂你在問什么了😭我的腦子已經沒辦法決議你的問題了😭)
面試官莫非是聽到了我的心聲，終于結束了這個死亡話題
MDN
當初始的 HTML 檔案被完全加載和決議完成之后，DOMContentLoaded 事件被觸發，而無需等待樣式表、影像和子框架的完全加載，
同步 JavaScript 會暫停 DOM 的決議，
如果您希望 DOM 在用戶請求頁面后盡可能快地決議，你可以做的一些事情是把你的 JavaScript 異步化 以及 優化樣式表的加載, 由于被并行加載而減慢頁面加載，從主 html 檔案“竊取”流量，
看到了一個講解詳細的鏈接: http://www.mamicode.com/info-detail-2839422.html
有了解過瀏覽器的快取嗎，怎么設定瀏覽器的快取
【我】：就是在請求的時候，如果服務器端回傳的回應頭中的cache-control是max-age的話，那就是強制快取，此時max-age的值就是快取時間，下一次客戶端向服務器請求的話，就會先去本地檢查一下本地是不是會有這個檔案，如果沒有過期的話，就從本地快取中讀取，如果過期的話，就繼續去服務器上獲取，如果服務器的cache-control的值是no-cache的話，就是協商快取，協商快取服務器還會同時回傳一個Last-Modify和ETag，Last-Modify是最后一次修改時間，ETag是根據這個檔案內容生成的唯一性標志，下一次客戶端去請求的時候，會攜帶上這個Last-Modify和ETag，給服務端做驗證，服務端優先使用ETag來判斷，如果服務端檔案修改了，那ETag就不一樣了，則匹配不上，客戶端如果沒有攜帶ETag的話，就用Last-Modify來判斷，判斷修改時間是不是與服務端一致，如果服務端判斷出客戶端資源檔案未修改，就回傳一個304狀態碼，讓客戶端去讀本地快取，否則就回傳200狀態碼和新的資源檔案，
【面試官】：如果強快取沒有過期的話，檔案發生了修改，那怎么更新這個快取呢
【我】：可以使用瀏覽器的重繪功能
【面試官】：你怎么控制用戶的瀏覽器呢
【我】：哦，就是開發人員弄這個操作是嗎，那還可以清除快取（此時我內心很慌😒，又開始亂說了）
【面試官】：那你怎么清除用戶瀏覽器上的快取呢
【我】：…(停頓10幾秒) 通過手動清除快取不算么，要通過狀態碼控制嗎（我已經控制不止自己在說啥了）
【面試官】：強快取沒有過期的時候，瀏覽器會發起請求嗎
【我】：不會，除非是重繪它
【面試官】：那你有一億個用戶，你要怎么給每個用戶重繪他的瀏覽器
【我】:…(又停頓了十幾秒)，哦，是哦，…, 我沒想到…
【面試官】：那你之前做過的專案有做過強快取嗎，一般都不處理這個…
【面試官】：為什么呢
【我】：因為這個是瀏覽器自帶的機制吧，后端設定的回應頭(我腦子里想講的應該是服務端，腦子已經昏掉了)
【面試官】：后端了解瀏覽器、了解前端的知識嗎(雖然我已經暈乎乎，但是面試官還很清醒😭)
【我】：可是這個不是后端回傳的嗎
【面試官】：那介面也是后端回傳的，內容不是前端定的嗎
【我】：前后端一起商量的…
如何更新強快取：檔案名根據內容哈希，
有了解過性能優化嗎
【我】：有了解過
【面試官】：性能優化有哪些措施和手段
【我】：從網路層面，減少請求次數，提高請求速度，這一塊可以通過快取和打包的數目來控制，還有代碼層面，開發人員寫的代碼要…(額，被打斷)
【面試官】：你剛才說通過快取，指的是什么
【我】：就是檔案快取，檔案內容不變，我們現在打包的檔案名不都是根據檔案內容生成的一個哈希名嘛，如果檔案內容不變，哈希值不變，瀏覽器就會用快取機制優先從快取中讀取，
【面試官】：剛才你不是說沒有設定這個快取嗎，那怎么會利用呢，你前面不是說沒有設定強快取嗎
【我】：額…那…還有協商快取
【面試官】：你覺得是強快取好還是協商快取好？
【我】：我覺得是協商快取好，因為協商快取每次會去校驗一下，如果本地快取可用的話，就可以讀本地快取了
【面試官】：那你不是相當于多了一次網路請求嗎，那這次要是卡住了，那頁面打開的速度就會變慢
【我】：但是能保證檔案新鮮及時
【面試官】：那用強快取就不能保證檔案新鮮及時了嗎
【我】：我沒有解決上面一個問題…(饒了我吧，腫么又繞到了上一題🥺🥺😭??)
【面試官】：嗯？
【我】：我說我沒有解決上面一個問題，就是說檔案修改了，那它就不知道了，哦，哎，我想起來了，就是你剛才說的上一個問題，就是強快取的檔案修改了，那再次發起請求的話，那檔案名變化了不就不能用本地的了嗎，我不就發起了新的一輪請求了嗎，這就破解了上一個問題了，對吧？
【面試官】：嗯，本來就應該是這個答案 (本可憐終于智商在線了┭┮﹏┭┮)
【我】：嗯，又繞回來了
【面試官】：嗯，就是說，你知道這個原理，但你之前沒有用過，所以沒有想到，對吧
【我】：嗯是的，剛才沒有想到，不過是說到了檔案變化了，就會導致檔案名變化了，那就會發起新的請求了，才想起來的
【面試官】：嗯，行
Ajax跨域都有哪幾種方式
【我】：JSONP、Nginx反向代理、Node中間件、CORS
【面試官】：你用過哪種
【我】：我用過Nginx，因為我們公司專案里用的就是Nginx，打包在docker里運行的
【面試官】：那相當于沒有跨域是吧
【我】：我們開發模式下用的是webpack中的Proxy代理
CORS是怎么實作的
【我】：前端要設定請求頭的origin為后端地址，后端也要設定allow回應頭，允許訪問的請求方式和IP地址
【面試官】：IP地址？那如果是CDN有很多個IP訪問呢？
【我】：那就設定為星號
【面試官】星號？那黑客不就可以非法訪問了嗎
【我】：CDN一般不是以script標簽、link標簽，這不是不會有跨域問題嗎
【面試官】：那用戶呢，每個用戶的IP都不一樣啊，你這個Ajax是用戶發起的啊
【我】：嗯，對
【面試官】：你沒有去練習過這個CORS的使用是嗎？
【我】：我之前學node的時候用過，但是只是練習的時候用的
【面試官】：那怎么設定回應頭呢
【我】：在node里面可以設定四五個回應頭，但名字很長，我可能記得不太全了
【面試官】：node使用什么方法設定的相應頭
【我】：express里面帶的設定回應頭
【面試官】：它的方法名叫什么
【我】：嗯…你是說設定方法頭的方法名嗎
【面試官】：嗯
【我】：是setHeader嗎
【面試官】：setHeader是嗎
【我】應該是的(其實我也不記得了💔node好久沒碰了)
在node中通過cors跨域，
cors ： 全稱 cross origin resource share 跨資源共享
在nodejs 中可以通過在服務器端設定代碼如下實作cors跨域
res.setHeader(‘Access-Control-Allow-Origin’, “*”); //針對哪個域名可以訪問，*表示所有
res.setHeader(‘Access-Control-Allow-Credentials’, true); //是否可以攜帶cookie
res.setHeader(‘Access-Control-Allow-Methods’, ‘POST, GET, PUT, DELETE, OPTIONS’);
// 在nodejs中，一般情況下是需要服務器代碼在我們控制范圍之內可以這樣做
app.use('*',(req,res,next) => {
res.setHeader('Access-Control-Allow-Origin','*');
res.setHeader('Access-Control-Allow-Credential','true');
res.setHeader('Access-Control-Allow-Methods','GET,POST,PUT,DELETE,OPTIONS');
next();
});
有了解怎么捕獲用戶瀏覽的網頁下的報錯嗎
【我】：可以通過try-catch捕獲，還可以通過監聽全域的事件error
【面試官】：error是在哪個物件上面？
【我】：在window上面
【面試官】：那你有用過嗎
【我】：我今天還碰巧試了一下，今天有別人問到我到了
【面試官】：你是今天有面試嗎
【我】：不是，是我一個朋友，他在他專案中用到了，他說在設定一個全域的監聽error不起作用，他就來問問我，我就幫他試了一下，我就在我專案里試了一下，我發現也沒起作用
【面試官】：那找到原因了嗎
【我】：沒有，我不知道是不是框架的原因，他用React的時候沒有捕獲到，我在我的React專案里試了一下，也沒有起作用，但是我寫在本地測驗是可以的
【面試官】：你這個本地測驗指什么，本地的React?
【我】：不是，就是普通的JS
【面試官】：React不普通嗎
【我】：就是一個HTML檔案里的script
【面試官】：原生是吧
【我】：對對對
【面試官】：那你在業務中并沒有使用到這個方法
【我】：恩是的，但我之前也學到過它， 要不然人家問起來我也不會知道它是啥了
有了解XSS攻擊嗎
【我】：點擊別人鏈接的時候，就帶著自己的資訊訪問了這個URL，自己的cookie資訊就泄漏了
【面試官】：那別人給你發一個百度的網站你點了會有問題嗎
【我】：額這個是沒問題，這個網址對你沒有破壞性，不過有的網址比如說支付類的，拿別人發一個鏈接給你，你點一下就帶著自己本地的cookie資訊請求了這個地址了
MDN
XSS ：Cross-site scripting（跨站腳本攻擊）
跨站腳本攻擊（Cross-site scripting，XSS）是一種安全漏洞，攻擊者可以利用這種漏洞在網站上注入惡意的客戶端代碼，當被攻擊者登陸網站時就會自動運行這些惡意代碼，從而，攻擊者可以突破網站的訪問權限，冒充受害者，根據開放式 Web 應用安全專案（OWASP），XSS 在 2017 年被認為 7 種最常見的 Web 應用程式漏洞之一，
如果 Web 應用程式沒有部署足夠的安全驗證，那么，這些攻擊很容易成功，瀏覽器無法探測到這些惡意腳本是不可信的，所以，這些腳本可以任意讀取 cookie，session tokens，或者其它敏感的網站資訊，或者讓惡意腳本重寫HTML內容，
在以下2種情況下，容易發生 XSS 攻擊：
- 資料從一個不可靠的鏈接進入到一個 Web 應用程式，
- 沒有過濾掉惡意代碼的動態內容被發送給 Web 用戶，
惡意內容一般包括 JavaScript，但是，有時候也會包括 HTML，FLASH 或是其他瀏覽器可執行的代碼，XSS 攻擊的形式千差萬別，但他們通常都會：將 cookies 或其他隱私資訊發送給攻擊者，將受害者重定向到由攻擊者控制的網頁，或是經由惡意網站在受害者的機器上進行其他惡意操作，
XSS 攻擊可以分為3類：存盤型（持久型）、反射型（非持久型）、DOM 型，存盤型 XSS：
注入型腳本永久存盤在目標服務器上，當瀏覽器請求資料時，腳本從服務器上傳回并執行，
反射型 XSS：
當用戶點擊一個惡意鏈接，或者提交一個表單，或者進入一個惡意網站時，注入腳本進入被攻擊者的網站，Web服務器將注入腳本，比如一個錯誤資訊，搜索結果等 回傳到用戶的瀏覽器上，由于瀏覽器認為這個回應來自"可信任"的服務器，所以會執行這段腳本，
基于 DOM 的 XSS：
通過修改原始的客戶端代碼，受害者瀏覽器的 DOM 環境改變，導致有效載荷的執行，也就是說，頁面本身并沒有變化，但由于DOM環境被惡意修改，有客戶端代碼被包含進了頁面，并且意外執行，
那CSRF攻擊有了解嗎
【我】：就是用戶在填寫文本的時候，可能填的是一段腳本，就是含有script標簽的JS代碼，提交后如果前后端都不對這個文本做轉義替換標簽處理的話，可能前端在渲染時，就會直接讓這段腳本在前端執行了
【面試官】：CSRF的全稱是什么
【我】：全稱…跨域攻擊？(我懷疑我把XSS和CSRF講反了!!)
【面試官】：跨域攻擊？那XSS的全稱是什么？ (我大概是真的講反了，涼!!)
【我】：我不會記反了吧？呵呵··(尷尬一笑····) 額，XSS的，我不記得了… 我是不是講反了
【面試官】：那XSS攻擊的具體原理是怎樣的
【我】：原理就是本地的cookie去請求一個地址
【面試官】：請求什么地址，誰拿著本地的cookie
【我】：點擊別人發給你的一個連接，帶著本地資訊請求了，get請求就發過去了
【面試官】：那為什么就會造成攻擊呢
【我】：他請求了這個get請求，對這個用戶產生了影響，比如說支付類、確定類，一個URL就是一個get介面
【面試官】：那為什么這個支付類的會產生攻擊呢，它具體是怎么實作的呢，那比如說我現在給你發一個支付鏈接，你點了就會被攻擊嗎
【我】：現在不會了，現在我點了的話，肯定會有驗證的，不會直接支付的，如果在有些網站，它沒有做驗證的話，只是用你的cookie判斷你的身份，那這個會造成攻擊的
【面試官】：為什么會拿著你的cookie呢
【我】：cookie會自動隨著http請求發送到服務器的
【面試官】：那有什么辦法讓它不發送嗎
【我】：可以禁掉cookie
【面試官】：那你自己的網站會受影響嗎
【我】：會， 額… 那開發這個網站的人可以換個請求方式
【面試官】：那Post就不會有這個問題嗎
【我】：我們點擊事件是Get請求過去的
【面試官】：我知道那Post會不會有這個漏洞
【我】：Post的話，沒有
參考網上這位大佬的文章：計算機網路 網路安全------XSS與CSRF的原理與防范
CSRF（Cross-site request forgery）跨站請求偽造，也被稱為“One Click Attack”或者Session Riding，通常縮寫為CSRF或者XSRF，是一種對網站的惡意利用，
盡管聽起來像跨站腳本（XSS），但它與XSS非常不同，XSS利用站點內的信任用戶，而CSRF則通過偽裝成受信任用戶的請求來利用受信任的網站，與XSS攻擊相比，CSRF攻擊往往不大流行（因此對其進行防范的資源也相當稀少）和難以防范，所以被認為比XSS更具危險性，
簡單的說，CSRF是攻擊者盜用你的名義來發送惡意訊息，如：以你的名義發郵件，購買物品，轉賬等，
如在一個轉賬的網站，當我們保持著登錄狀態沒有退出，然后這時候被誘導訪問了另一個網站，該網站內有張不可顯示的圖片這是攻擊者利用圖片資源嵌入了惡意的轉賬操作，所以可以在我們不知情的情況下轉走我們的錢錢，
但上述例子是一個 GET 請求下的操作，那如果是 POST 請求呢？
這時候只需要在誘導用戶訪問的頁面內嵌一個表單，通過表單自動提交也可以做到惡意轉賬，
CSRF的防范
CSRF 的本質原因是由于服務端的身份驗證不夠，僅僅通過校驗 session 來判斷，但這并不能保證所有的操作都是用戶發起的，所以要防范 CSRF 得加強在服務端的校驗處理，
盡量使用 POST
因為 GET 請求實在是太容易被利用了，如上述的例子，只需要一個 img 的標簽，而 img 又是不能過濾的資料，所以介面最好限制為 POST 請求，加入驗證碼
因為 CSRF 都是偷偷盜用用戶名義發送的，我們只需要加入驗證碼校驗，就可以確定該操作是用戶自己的行為而不是盜用用戶名義的行為，驗證Referer
HTTP 頭上有一個 Referer 欄位，記錄了該請求的源地址，黑客要發起 CSRF 的攻擊只能從他們自己的網站構建請求，源地址不會是用戶的地址，但道高一尺魔高一丈，雖然 Referer 的值是由瀏覽器提供的，但在某些瀏覽器上我們可以篡改 Referer 的值，所以有時候也并不安全，Token
我們知道黑客只能冒用了我們的身份發送請求，所以我們只每次發送的請求帶上一個黑客所不能偽造的驗證資訊，并且資訊不能存在與 cookie 中，所以我們可以在 HTTP 的請求頭中加入一個隨機產生的 token（分布式環境下的 token 生成有點不同），客戶端回傳訊息時驗證該 token 是否一致，若不一致則認為這是一次 CSRF 攻擊，
平時有遇到過安全方面的問題或事件嗎
【我】：我以前在學校里面寫代碼的時候遇到過，可能那時候我對前端懂得也不是那么多，當時做學校的網站，有個支付功能的，我把金額、購買的東西這些資訊放在前端提交過去，然后就有人攔截了請求，修改了資料再提交，導致訂單不對了，之后我就是在用戶確定下單的時候，生成一條待支付訂單，然后用戶提交的時候，帶著訂單編號過去，這樣他就沒法修改訂單里的資訊了
【面試官】：…
【我】：我覺得這種重要資訊都不能放在前端，應該存在后端，前端就拿著一個編號就好了
這個問題第二次被問到了，不知道怎么回答比較好
你現在的專案中有難度或者有挑戰的地方嗎
【我】：我現在在我們公司就是做集團的管理系統的，每天的作業內容都差不多，所以我才想去更好的公司的，才有可能遇到更多的有挑戰性的問題
【面試官】：一直都是做管理系統，沒有做過別的是嗎
【我】：我就做了一年，因為我來這個公司也就一年，也就做了兩個嘛，不過我作業中肯定要做這個啊，有時候還做做組件，因為有些頁面會有作業的組件，需要抽出來做，還有我們管理系統還有移動端，移動端是一個學習平臺，不過移動端也是用React做的，我現在這段時間做移動端的這個學習APP更多一點，要不然一直做管理系統很無聊，所以我才想去跳槽去好公司，否則這個專案結束了又要進入下一個專案做管理系統，太無聊了
【面試官】：那管理系統有沒有考慮做一個通用的管理中臺這個東西呢，可以自動去搭建管理系統的
【我】：整個管理系統我倒是沒有，但是我做了模塊的自動生成，就是用Plop那個工具，可以自動化生成頁面
【面試官】：怎么自動化生成
【我】：那個Plop不是前端的一個自動化工具嘛，先在專案中安裝plop，然后在它的組態檔plopfile中寫它的互動命令，輸入你的模塊名、介面名、欄位名，它就根據模板生成檔案，你所填入的資訊都會替換進去，替換到模板的占位符中去，就能很快的生成一個一個頁面，因為管理系統頁面都很相似，我通過plop批量生成了一些模塊之后，每個模塊只需要再稍微改動一下就行了，這個是我前幾個月的時候學到的plop這個工具，我就在我們專案里試了試
你的頁面上一個按鈕點擊會發送一個Ajax請求到后臺，后臺回傳成功或失敗給個提示，然后有一天你收到一個反饋，按鈕點擊之后沒有反應，但你不知道是誰反饋的，也找不到這個人，然后你在你的電腦上試了下，并沒有問題，那你會怎么分析定位這個原因呢
【我】：在我電腦上沒問題，那可能跟他電腦有關，那我先讓其他同事也都試一下，看看有沒有問題
【面試官】：那其他同事都沒有呢
【我】：那可能是他電腦有問題吧… (emmmm…知識盲區)
【面試官】：你是說是他的問題不是你代碼的問題？
【我】：如果我讓同事們試了都沒問題，那就可能跟他那邊的環境有關系了
【面試官】：那你分析這個問題的原因有沒有辦法，你分析的思路是怎樣的
【我】：得想辦法定位到這個人，那還好搞一點
【面試官】：找不到這個人 (面試官難道是被這種事虐過么…)
【我】：找不到這個人的話，那就很難辦了，那我怎么辦… (我的腦子真的轉不過來了…)
【面試官】：就沒有辦法了是嗎
【我】：我、我不知道，因為我們現在做的系統都是集團的，如果遇到問題會有人一輪一輪報上來，都是能找到報錯人的，還能定位一下問清楚，如果不知道是誰報出的錯誤，你也不知道他的環境，就光靠他說一句他報錯了，那可能還是他操作有問題…
這個沒想到，得問問我的群友們
知道怎么檢測頁面的性能資料并上報嗎
【我】：沒有
【面試官】：知道怎么去獲取性能資料嗎
【我】：chrome瀏覽器好像就支持，它底部有個performance面板
【面試官】：用JS怎么獲取呢
【我】：哦，JS啊，JS我記得它好像有個方法，但我記得不太清楚了，它有個方法可以獲取到網頁每一階段的時間，加載時間、回應的時間、渲染的時間，但那個方法名我不記得了，因為好像那個名字還有點長…
【面試官】：嗯
我當時想的是performance，面試官想問的應該是它吧
參考這位大佬的文章：Performance：前端頁面性能監控
Performance是HTML5提供的，用于獲取當前頁面中與性能相關的資訊（如：頁面每個處理階段精確時間）的API，可以通過呼叫只讀屬性 window.performance來獲得，
Performance.timing屬性分析：
navigationStart：當前瀏覽器視窗的前一個網頁關閉發生unload事件時的Unix毫秒時間戳，如果沒有前一個網頁，則等于fetchStart屬性，
unloadEventStart：如果有前一個網頁，且與當前網頁同源，則回傳前一個網頁unload事件發生時的Unix毫秒時間戳，如果沒有前一個網頁，或前一個網頁與當前網頁不同源，則回傳值為0，
unloadEventEnd：如果有前一個網頁，且與當前網頁同源，則回傳前一個網頁unload事件的回呼函式結束時的Unix毫秒時間戳，如果沒有前一個網頁，或前一個網頁與當前網頁不同源，則回傳值為0，
redirectStart：回傳第一個HTTP跳轉開始時的Unix毫秒時間戳，如果沒有跳轉，或者不同源，則回傳值為0，
redirectEnd：回傳最后一個HTTP跳轉結束時的Unix毫秒時間戳，如果沒有跳轉，或者不同源，則回傳值為0，
fetchStart：回傳瀏覽器準備使用HTTP請求讀取檔案時的Unix毫秒時間戳，該事件在網頁查詢本地快取之前發生，
domainLookupStart：回傳域名查詢開始時的Unix毫秒時間戳，如果使用持久連接，或者資訊是從本地快取獲取，則回傳值等同于fetchStart屬性的值，
domainLookupEnd：回傳域名查詢結束時的Unix毫秒時間戳，如果使用持久連接，或者資訊是從本地快取獲取，則回傳值等同于fetchStart屬性的值，
connectStart：回傳HTTP請求開始向服務器發送時的Unix毫秒時間戳，如果使用持久連接，則回傳值等同于fetchStart屬性的值，
connectEnd：回傳瀏覽器與服務器之間的連接建立（連接建立指所有的握手和認證程序全部結束）時的Unix毫秒時間戳，如果使用持久連接，則回傳值等同于fetchStart屬性的值，
secureConnectionStart：回傳瀏覽器與服務器開始安全連接的握手時的Unix毫秒時間戳，如果當前網頁不要求安全連接，則回傳0，
requestStart：回傳瀏覽器向服務器發出HTTP請求時（或開始讀取本地快取時）的Unix毫秒時間戳，
responseStart：回傳瀏覽器從服務器收到（或從本地快取讀取）第一個位元組時的Unix毫秒時間戳，
responseEnd：回傳瀏覽器從服務器收到（或從本地快取讀取）最后一個位元組時（如果在此之前HTTP連接已經關閉，則回傳關閉時）的Unix毫秒時間戳，
domLoading：回傳當前網頁DOM結構開始決議時（即Document.readyState屬性變為loading，相應的readystatechange事件觸發時）的Unix毫秒時間戳，
domInteractive：回傳當前網頁DOM結構決議結束、開始加載內嵌資源時（即Document.readyState屬性變為interactive，相應的readystatechange事件觸發時）的Unix毫秒時間戳，
domContentLoadedEventStart：回傳當前網頁DOMContentLoaded事件發生時（即DOM結構決議完畢、所有腳本開始運行時）的Unix毫秒時間戳，
domContentLoadedEventEnd：回傳當前網頁DOMContentLoaded事件結束時的Unix毫秒時間戳，
domComplete：回傳當前網頁DOM結構生成時（即Document.reayState屬性變為complete，以及相應的readystatechange事件發生時）的Unix毫秒時間戳，
loadEventStart：回傳當前網頁load事件的回呼函式開始時的Unix毫秒時間戳，如果該事件還沒發生，回傳0，
loadEventEnd：回傳當前網頁load事件的回呼函式結束時的Unix毫秒時間戳，如果該事件還沒發生，回傳0，
通過以上屬性，可以計算出網頁加載各個階段的耗時，比如：
DNS查詢：domainLookupEnd - domainLookupStart
TCP連接：connectEnd - connectStart
TTI（頁面可互動時間）：domInteractive - navigationStart
domready時間：domContentLoadedEventEnd - navigationStart
onl oad：loadEventEnd - navigationStart
【面試官】：那我這邊就沒有其他問題了，今天的面試就先到這里，我們這邊考慮之后有訊息的話再聯系你
【我】：嗯，好，謝謝
【面試官】：拜拜
花了幾個小時復盤了一遍，感覺自己答得不好，很凌亂，不流暢，尤其是XSS和CSRF那一塊混淆了，不清晰，講錯了，
繼續加油吧！
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/198394.html
標籤：其他
上一篇：ACL配置技術檔案
下一篇：重裝系統感悟之設定系統還原點