(=@__@=)前一天晚上因為甲方的逼迫通宵改項目，第二天阿里面試
狀態(tài)很糟糕，剛剛回學?？纪暝嚴玻F(xiàn)在來記錄一下面試的過程??
一面
(和藹的) 介紹一下你的學習經歷~
(懵逼的) HTML5，CSS3，JavaScript，PHP+MySQL，nodeJS，Angular.JS，Vue.JS，最近在學react
(超級喜(猥)悅(瑣)) 你知不知道面試的時候提Angular和Vue是很危險的呀~
(開心的) 那我們來幾個最最最基本的問題吧
(終于進入正題了啊) 嗯嗯！
(正經的) 來講講跨域
(依舊懵逼的)
最普通的有CORS(但是當時懵逼的我說成了CSRF，大寫的囧)，服務端允許跨域。這個會有簡單請求和復雜請求兩種。簡單請求就是 GET請求( 除了Content-Type是json格式 )，復雜請求就是除此之外的請求。 區(qū)別就是復雜請求在發(fā)送正式請求之前會提前發(fā)送一個OPTIONS請求，服務端如果允許了這個OPTIONS請求，那就會接著去發(fā)正式請求。
然后就是 jsonp ，通過帶有src屬性的標簽就可以跨域訪問。在標簽的回調函數(shù)里添加對請求到的數(shù)據的處理方法就可以啦~
(嚴肅的) 別的呢？？
(想了想) 還有iframe
(恍然大悟) 對了，前些天做項目的時候用到了h5的postMessage，后臺那邊在官網添加首頁圖片預覽。本地調試時在我的代碼里引用一個帶有他域名的js文件，就可以實現(xiàn)了后臺添加圖片的實時預覽。
(繼續(xù)問) 還有呢？？
(懵逼的) ？？
(告訴我) 還有domain和flash然后balabala(我現(xiàn)在具體想不來了其實= =)
(笑的超開心)來談談(你剛剛提到的)CSRF
(反應過來并假裝自己剛剛什么都沒有說然后一本正經的說)
跨站偽造請求嘛，典型的可以通過盜取cookie來得到用戶的各種權限。
(微笑) 只有這樣？
(繼續(xù)正經) 那其實可以插入js的話也就等同于可以做任何事情了。其實有時候和XSS會有點像。
(正經臉) CSRF和XSS是完全不同的。
(懵逼) (⊙o⊙)
(正經講解臉) 跨站請求偽造是一種挾制用戶在當前已登錄的Web應用程序上執(zhí)行非本意的操作的攻擊方法。跟跨網站腳本（XSS）相比，XSS 利用的是用戶對指定網站的信任，CSRF 利用的是網站對用戶網頁瀏覽器的信任。攻擊者并不能通過CSRF攻擊來直接獲取用戶的賬戶控制權，也不能直接竊取用戶的任何信息。他們能做到的，是欺騙用戶瀏覽器，讓其以用戶的名義執(zhí)行操作。
(開心的) 原理告訴你了，來，猜猜看怎么防御
(懵逼的) 可不可以直接屏蔽掉所有的外來js ?。?？
(嚴肅的) 不是這個問題
(想了想) 應該是類似瀏覽器同源策略的方法吧，通過限制特點的域名下的js才能對網站進行訪問
(正經臉繼續(xù)解釋) 檢查Referer字段，HTTP頭中有一個Referer字段，這個字段用以標明請求來源于哪個地址。在處理敏感數(shù)據請求時，通常來說，Referer字段應和請求的地址位于同一域名下。
還有呢？？
(此時已經完全懵) 想不出來了
(正經臉) Web Authentication知道嗎？
(正經臉) 嗯嗯，前些天做項目時有遇到。在用戶登錄后再向服務端發(fā)送請求時都會要求攜帶token，只有token正確服務端才會返回數(shù)據。
(好奇臉) 那token就一定安全了嘛？
(懵逼) 似乎不吧，萬一cookie被盜用??
(嫌棄臉) 現(xiàn)在的網站有那么不安全嗎，其實 token就已經完全可以防御CSRF了
那想想在阿里CSRF防御可以用在哪些地方？
(懵逼臉) 支付的過程吧
(我覺得他已經進入講解狀態(tài)了科科) 就拿支付寶說，如果盜用了用戶權限，隨意修改一下轉賬的account和轉賬的money，嗯，錢就沒有了。
此時我的心情：
(愉悅臉) 來來我們先來談一下這個你剛剛提到的angular，它是mvvm結構，那它是怎么實現(xiàn)數(shù)據雙向綁定的？
(完全懵逼) 不是很清楚
(超爽快) 來，手機給你，兩分鐘，自己查完給我講
--------------認真百度的分割線-------------
(正經臉) Angular的數(shù)據綁定主要是通過中間的ViewModel層($scope)來實現(xiàn)的。引入了專門的ViewModel（視圖模型）來實現(xiàn)View和Model的粘合，讓View和Model的進一步分離。
--------------認真裝逼的分割線-------------
http://imweb.io/topic/55c05482193684376cd08b53
https://www.zhihu.com/question/23275373
http://www.alloyteam.com/2015/06/mvvm-xue-xi-vue-shi-jian-xiao-jie/
剛剛看完上面這些，覺得自己too young too native
(繼續(xù)愉快臉) 來談談你對spa的看法吧
(spa是個啥？？) 不好意思我沒聽清楚??
(正經臉) Single Page Application
(恍然大悟臉，不知道明顯不明顯) 我認為單頁應用適合邏輯明確，需要組件復用的web應用。
我就一下講我的項目舉個栗子??吧~
例如項目中 header和footer的包括其中的一些 componet(about頁面和登錄頁面)都是可以重復使用的。中間router-view部分的頁面跳轉通過vue-router來進行。
(好奇臉) 那spa如何優(yōu)化？
(有點懵) 壓縮css，js，減少http請求，在請求http時使用vue-resource ，在請求localStorage時使用對應的組件。
(愉悅臉) 你的意思是要清空緩存嘍？
(????其實并沒有想到) 嗯嗯
(?(?*)) 那你為什么選擇Vue呢？
(誠實的(。??)ノ) 老師讓。
(??估計沒想到我這么誠實) 那你自己的想法呢？
(思考臉) 比起Angular更加輕量，API更少，但是實用性蠻強。
(認真臉) 我覺得Vue也還是太重了,也就是說你在用它的時候沒有考慮過為什么你們老師選擇用Vue嗎？
(此時我的臉色應該很苦/(ㄒoㄒ)/~~)
那我就說說我用的感受吧。
文檔很詳細，寫法很簡潔。
另外數(shù)據綁定沒有Angular那么方便是雙向，當model層一些復雜數(shù)據(例如數(shù)組)發(fā)生變化時，Vue是檢測不到的，需要增加watch來監(jiān)測這些變化。
沒有RootScope，同級組件之間傳遞信息復雜。目前我的解決方法是，a先將信息冒泡到父組件父組件再廣播b組件再接收。
(正經臉) ok，那其實框架只是一種選擇。比起會用API更要緊的是你要知道為什么要選擇它，了解它的優(yōu)點和缺點，要知道框架中的功能都是怎么實現(xiàn)的
(疑惑臉) 那怎么去了解框架相關功能的實現(xiàn)？通過閱讀源碼嗎？
(笑了) 有的框架源碼可讀性太差了況且如果對工程化沒有一個很明確的理解的話讀起來也是非常吃力的。
(小雞啄米一樣點頭??)
((≧▽≦)/)我的問題結束了，那你有什么問題問我呢？
(這個部分我就不寫，嘻嘻)
其實過了一天加上當時狀態(tài)很糟糕，真正的過程應該遠沒有寫的這么流暢，本來當時都準備背著包去上班了。
結果被叫住說我這關你過了，可以去外面等??
二面明天再寫
