百度、有贊、阿里前端面試總結
來源：
奇酷教育 發表于：
以下為百度、有贊、阿里的前端面試總結，請大家參考：
以下為百度、有贊、阿里的前端面試總結，請大家參考：
一面
先完成筆試題：
1、實現一個函數，判斷輸入是不是回文字符串。
2、兩種以上方式實現已知或者未知寬度的垂直水平居中。
3、實現效果，點擊容器內的圖標，圖標邊框變成border 1px solid red，點擊空白處重置。
4、請簡單實現雙向數據綁定mvvm。
5、實現Storage，使得該對象為單例，并對localStorage進行封裝設置值setItem(key,value)和
你的技術棧主要是react，那你說說你用react有什么坑點？
1、JSX做表達式判斷時候，需要強轉為boolean類型，如：
這是一段文本
如果不使用 !!b 進行強轉數據類型，會在頁面里面輸出 0。
2、盡量不要在 componentWillReviceProps 里使用 setState，如果一定要使用，那么需要判斷結束條件，不然會出現無限重渲染，導致頁面崩潰。
3、給組件添加ref時候，盡量不要使用匿名函數，因為當組件更新的時候，匿名函數會被當做新的prop處理，讓ref屬性接受到新函數的時候，react內部會先清空ref，也就是會以null為回調參數先執行一次ref這個props，然后在以該組件的實例執行一次ref，所以用匿名函數做ref的時候，有的時候去ref賦值后的屬性會取到null。詳情見
4、遍歷子節點的時候，不要用 index 作為組件的 key 進行傳入。
我現在有一個button，要用react在上面綁定點擊事件，要怎么做？
我點擊了按鈕') }}> 按鈕
接上一個問題，你覺得你這樣設置點擊事件會有什么問題嗎？
由于onClick使用的是匿名函數，所有每次重渲染的時候，會把該onClick當做一個新的prop來處理，會將內部緩存的onClick事件進行重新賦值，所以相對直接使用函數來說，可能有一點的性能下降（個人認為）。
修改：
我點擊了按鈕') } render() { return
當然你在內部聲明的不是箭頭函數，然后你可能需要在設置onClick的時候使用bind綁定上下文，這樣的效果和先前的使用匿名函數差不多，因為bind會返回新的函數，也會被react認為是一個新的prop。
你說說event loop吧
首先，js是單線程的，主要的任務是處理用戶的交互，而用戶的交互無非就是響應DOM的增刪改，使用事件隊列的形式，一次事件循環只處理一個事件響應，使得腳本執行相對連續，所以有了事件隊列，用來儲存待執行的事件，那么事件隊列的事件從哪里被push進來的呢。那就是另外一個線程叫事件觸發線程做的事情了，他的作用主要是在定時觸發器線程、異步HTTP請求線程滿足特定條件下的回調函數push到事件隊列中，等待js引擎空閑的時候去執行，當然js引擎執行過程中有優先級之分，首先js引擎在一次事件循環中，會先執行js線程的主任務，然后會去查找是否有微任務microtask（promise），如果有那就優先執行微任務，如果沒有，在去查找宏任務macrotask（setTimeout、setInterval）進行執行。
說說事件流吧
事件流分為兩種，捕獲事件流和冒泡事件流。
捕獲事件流從根節點開始執行，一直往子節點查找執行，直到查找執行到目標節點。
冒泡事件流從目標節點開始執行，一直往父節點冒泡查找執行，直到查到到根節點。
事件流分為三個階段，一個是捕獲節點，一個是處于目標節點階段，一個是冒泡階段。
我現在有一個進度條，進度條中間有一串文字，當我的進度條覆蓋了文字之后，文字要與進度條反色，怎么實現？
。。。當時我給的是js的方案，在進度條寬度變化的時候，計算蓋過每一個文字的50%，如果超過，設置文字相反顏色。
當然css也有對應的方案，也就是 mix-blend-mode，我并沒有接觸過。
對應html也有對應方案，也就設置兩個相同位置但是顏色相反的dom結構在重疊在一起，頂層覆蓋底層，最頂層的進度條取overflow為hidden，其寬度就為進度。
二面
你為什么要離開上一家公司？
你覺得理想的前端地位是什么？
那你意識到問題所在，你又嘗試過解決問題嗎？
三面
說一下你上一家公司的一個整體開發流程吧
的虛擬dom是怎么實現的
首先說說為什么要使用Virturl DOM，因為操作真實DOM的耗費的性能代價太高，所以react內部使用js實現了一套dom結構，在每次操作在和真實dom之前，使用實現好的diff算法，對虛擬dom進行比較，遞歸找出有變化的dom節點，然后對其進行更新操作。為了實現虛擬DOM，我們需要把每一種節點類型抽象成對象，每一種節點類型有自己的屬性，也就是prop，每次進行diff的時候，react會先比較該節點類型，假如節點類型不一樣，那么react會直接刪除該節點，然后直接創建新的節點插入到其中，假如節點類型一樣，那么會比較prop是否有更新，假如有prop不一樣，那么react會判定該節點有更新，那么重渲染該節點，然后在對其子節點進行比較，一層一層往下，直到沒有子節點。
的渲染過程中，兄弟節點之間是怎么處理的？也就是key值不一樣的時候。
通常我們輸出節點的時候都是map一個數組然后返回一個ReactNode，為了方便react內部進行優化，我們必須給每一個reactNode添加key，這個key prop在設計值處不是給開發者用的，而是給react用的，大概的作用就是給每一個reactNode添加一個身份標識，方便react進行識別，在重渲染過程中，如果key一樣，若組件屬性有所變化，則react只更新組件對應的屬性；沒有變化則不更新，如果key不一樣，則react先銷毀該組件，然后重新創建該組件。
我現在有一個數組[1,2,3,4]，請實現算法，得到這個數組的全排列的數組，如[2,1,3,4]，[2,1,4,3]。。。。你這個算法的時間復雜度是多少
這個我沒寫出來，大概給了個思路，將每一個數組拆除倆個小數組進行求它的全排列，然后得到的結果互相之間又進行全排列，然后把最后的結果連接起來。。。
感興趣的同學見數組全排列
我現在有一個背包，容量為m，然后有n個貨物，重量分別為w1,w2,w3...wn，每個貨物的價值是v1,v2,v3...vn，w和v沒有任何關系，請求背包能裝下的最大價值。
這個我也沒寫出來，也給了個思路，首先使用Q4的方法得到貨物重量數組的全組合（包括拆分成小數組的全組合），然后計算每一個組合的價值，并進行排序，然后遍歷數組，找到價值較高切剛好能裝進背包m的組合。
本題 動態規劃面試題，感興趣的同學請自行百度或者谷歌。
四面
請說一下你的上一家公司的研發發布流程。
你說一下webpack的一些plugin，怎么使用webpack對項目進行優化。
正好最近在做webpack構建優化和性能優化的事兒，當時吹了大概15~20分鐘吧，插件請見webpack插件歸納總結。
構建優化：
減少編譯體積 ContextReplacementPugin、IgnorePlugin、babel-plugin-import、
并行編譯 happypack、thread-loader、uglifyjsWebpackPlugin開啟并行
緩存 cache-loader、hard-source-webpack-plugin、uglifyjsWebpackPlugin開啟緩存、babel-loader開啟緩存
預編譯 dllWebpackPlugin && DllReferencePlugin、
性能優化：
減少編譯體積 Tree-shaking、
緩存
拆包 splitChunksPlugin、import()、
的new實例和es5的new實例有什么區別
這個我覺得是一樣的（當時因為很少看babel編譯之后的結果），面試官說不一樣。。。后來我看了一下babel的編譯結果，發現只是類的方法聲明的過程不一樣而已，最后new的結果是一樣的。。。具體答案現在我也不知道。。。
看你簡歷上寫了canvas，你說一下為什么canvas的圖片為什么過有跨域問題
圖片為什么跨域我不知道，至今沒查出來，也差不多，大概跨域原因和瀏覽器跨域的原因是一樣的吧。
我現在有一個canvas，上面隨機布著一些黑塊，請實現方法，計算canvas上有多少個黑塊
使用getImageData獲取像素數組，然后遍歷數組，把在遍歷節點的過程中，查看節點上下左右的像素顏色是否相同，如果相同，然后設置標識，最后groupBy一下所有像素。（這是我當時的方案）
其他更好的答案見地址
請手寫實現一個
這個就不寫了，詳情見promise實現原理
注：四面是一個超級可愛的小姐姐，電腦給我讓我寫完之后，我說我寫得差不多了，然后電腦給她，然后她竟然默默的在看我的代碼，嘗試尋找我的思路，也沒有問我實現思路是啥，然后我就問她，你不應該是讓我給你解釋我的代碼思路嗎。。。你竟然在嘗試尋找我的思路，我自己都不知道我自己是思路是啥。。。然后我兩都笑了，哈哈哈。最后結束的時候我說我午飯還沒吃，她還叫了另外一個小哥哥先帶了下去吃飯，真是一個善良的小姐姐，非常感謝。
五面
你說一下你的技術有什么特點
說一下你覺得你最得意的一個項目？你這個項目有什么缺陷，弊端嗎？
現在有那么一個團隊，假如讓你來做技術架構，你會怎么做？
考慮到團隊每一個前端的技術棧可能不一致，這個時候我可能選擇微前端架構，讓每個人負責的模塊可以單獨開發，單獨部署，單獨回滾，不依賴于其他項目模塊，在盡可能的情況下節約團隊成員之間的學習成本，當然這肯定也有缺點，那就是每個模塊都需要一個前端項目，單獨部署，單獨回滾無疑也加大了運維成本。
說一下你上一家公司的主要業務流程，你參與到其中了嗎？
杭州有贊
一面 WEB前端工程師 電話面 全程43分鐘
自我介紹
說說從輸入URL到看到頁面發生的全過程，越詳細越好
首先瀏覽器主進程接管，開了一個下載線程。
然后進行HTTP請求（DNS查詢、IP尋址等等），中間會有三次捂手，等待響應，開始下載響應報文。
將下載完的內容轉交給Renderer進程管理。
進程開始解析css rule tree和dom tree，這兩個過程是并行的，所以一般我會把link標簽放在頁面頂部。
解析繪制過程中，當瀏覽器遇到link標簽或者script、img等標簽，瀏覽器會去下載這些內容，遇到時候緩存的使用緩存，不適用緩存的重新下載資源。
和dom tree生成完了之后，開始合成render tree，這個時候瀏覽器會進行layout，開始計算每一個節點的位置，然后進行繪制。
繪制結束后，關閉TCP連接，過程有四次揮手。
你剛剛說了三次握手，四次揮手，那你描述一下？
本人對計算機網絡的這些概念一直不是很熟悉，所以這個問題回答不會，這里mark下文章，感興趣的同學查看地址
剛剛Q2中說的CSS和JS的位置會影響頁面效率，為什么？
在加載過程中不會影響到DOM樹的生成，但是會影響到Render樹的生成，進而影響到layout，所以一般來說，style的link標簽需要盡量放在head里面，因為在解析DOM樹的時候是自上而下的，而css樣式又是通過異步加載的，這樣的話，解析DOM樹下的body節點和加載css樣式能盡可能的并行，加快Render樹的生成的速度。
腳本應該放在底部，原因在于js線程與GUI渲染線程是互斥的關系，如果js放在首部，當下載執行js的時候，會影響渲染行程繪制頁面，js的作用主要是處理交互，而交互必須得先讓頁面呈現才能進行，所以為了保證用戶體驗，盡量讓頁面先繪制出來。
現在有一個函數A和函數B，請你實現B繼承
方式1function B(){}function A(){}B.prototype = new A();// 方式2function A(){}function B(){ A.call(this);}// 方式
剛剛你在Q5中說的幾種繼承的方式，分別說說他們的優缺點
方式1：簡單易懂，但是無法實現多繼承，父類新增原型方法/原型屬性，子類都能訪問到
方式2：可以實現多繼承，但是只能繼承父類的實例屬性和方法，不能繼承原型屬性/方法
方式3：可以繼承實例屬性/方法，也可以繼承原型屬性/方法，但是示例了兩個A的構造函數
說說CSS中幾種垂直水平居中的方式
參考前面百度一面筆試題
中說的flex布局，垂直水平居中必須知道寬度嗎？
是的，必須知道高度(腦子進水了回答了必須知道，其實答案是不需要知道高度的
描述一下
函數執行的上下文，可以通過apply，call，bind改變this的指向。對于匿名函數或者直接調用的函數來說，this指向全局上下文（瀏覽器為window，nodejs為global），剩下的函數調用，那就是誰調用它，this就指向誰。當然還有es6的箭頭函數，箭頭函數的指向取決于該箭頭函數聲明的位置，在哪里聲明，this就指向哪里。
說一下瀏覽器的緩存機制
瀏覽器緩存機制有兩種，一種為強緩存，一種為協商緩存。
對于強緩存，瀏覽器在第一次請求的時候，會直接下載資源，然后緩存在本地，第二次請求的時候，直接使用緩存。
對于協商緩存，第一次請求緩存且保存緩存標識與時間，重復請求向服務器發送緩存標識和最后緩存時間，服務端進行校驗，如果失效則使用緩存。
協商緩存方案：
1：服務端的響應頭，第一次請求的時候，告訴客戶端，該資源什么時候會過期。Exprires的缺陷是必須保證服務端時間和客戶端時間嚴格同步。
2：max-age，表示該資源多少時間后過期，解決了客戶端和服務端時間必須同步的問題，
3：緩存標識，對比緩存時使用它來標識一個緩存，第一次請求的時候，服務端會返回該標識給客戶端，客戶端在第二次請求的時候會帶上該標識與服務端進行對比并返回If-None-Match標識是否表示匹配。
4：第一次請求的時候服務端返回Last-modified表明請求的資源上次的修改時間，第二次請求的時候客戶端帶上請求頭If-Modified-Since，表示資源上次的修改時間，服務端拿到這兩個字段進行對比。
是這個字符串是怎么生成的？
沒答出來，我當時猜是根據文件內容或者最后修改時間進行的加密算法。其實官方沒有明確指定生成ETag值的方法。 通常，使用內容的散列，最后修改時間戳的哈希值，或簡單地使用版本號。
現在要你完成一個Dialog組件，說說你設計的思路？它應該有什么功能？
該組件需要提供hook指定渲染位置，默認渲染在body下面。
然后改組件可以指定外層樣式，如寬度等
組件外層還需要一層mask來遮住底層內容，點擊mask可以執行傳進來的onCancel函數關閉Dialog。
另外組件是可控的，需要外層傳入visible表示是否可見。
然后Dialog可能需要自定義頭head和底部footer，默認有頭部和底部，底部有一個確認按鈕和取消按鈕，確認按鈕會執行外部傳進來的onOk事件，然后取消按鈕會執行外部傳進來的onCancel事件。
當組件的visible為true時候，設置body的overflow為hidden，隱藏body的滾動條，反之顯示滾動條。
組件高度可能大于頁面高度，組件內部需要滾動條。
只有組件的visible有變化且為ture時候，才重渲染組件內的所有內容。
你覺得你做過的你覺得最值得炫耀的項目？
螞蟻金服-體驗技術部 資深數據可視化研發工程師
一面 電話面 全程1小時24分鐘
描述一下你最近做的可視化的項目
剛剛說的java調用js離線生成數據報告？java調用js的promise異步返回結果怎么實現的？
使用java的js引擎Nashorn，Nashorn不支持事件隊列，是要引進polyfill，然后java調用js方法獲得java的promise對象，然后在調用該對象的then方法，回調函數為java中的某各類的某個方法，然后while一個表示是否已執行回調的變量，如果未執行，則讓java主線程sleep，如果已經執行，則跳出循環，表示是否已執行回調的變量在傳入promise的回調函數中設置更改。詳情代碼見地址
說說svg和canvas各自的優缺點？
共同點：都是有效的圖形工具，對于數據較小的情況下，都很又高的性能，它們都使用 JavaScript 和 HTML；它們都遵守萬維網聯合會 (W3C) 標準。
優點：
矢量圖，不依賴于像素，無限放大后不會失真。
以dom的形式表示，事件綁定由瀏覽器直接分發到節點上。
缺點：
形式，涉及到動畫時候需要更新dom，性能較低。
優點：
定制型更強，可以繪制繪制自己想要的東西。
非dom結構形式，用JavaScript進行繪制，涉及到動畫性能較高。
缺點：
事件分發由canvas處理，繪制的內容的事件需要自己做處理。
依賴于像素，無法高效保真，畫布較大時候性能較低。
你剛剛說的canvas渲染較大畫布的時候性能會較低？為什么？
因為canvas依賴于像素，在繪制過程中是一個一個像素去繪制的，當畫布足夠大，像素點也就會足夠多，那么想能就會足夠低。
假設我現在有5000個圓，完全繪制出來，點擊某一個圓，該圓高亮，另外4999個圓設為半透明，分別說說用svg和canvas怎么實現？
首先，從數據出發，我們的每個圓是一個數據，這個數據有圓的x、y、radius、isHighlight如果是svg，直接渲染節點即可，然后往節點上邊綁定點擊事件，點擊改變所有數據的高亮屬性（必須同步執行完成），然后讓瀏覽器進行繪制。如果是canvas，我們需要自己綁定事件到canvans標簽上，然后點擊的時候判斷點擊的位置是否在圓內，如果在某個圓內，則更新所有數據的高亮屬性，之后在進行一次性繪制。
剛剛說的canvas的點擊事件，怎么樣實現？假如不是圓，這些圖形是正方形、長方形、規則圖形、不規則圖形呢
針對于每一個形狀，將其抽象成shape類，每一個類有自己的方法isPointInSide來判斷節點是否在圖形內，對于不規則圖形，當做矩形處理，點擊的時候執行該方法判斷點擊位置是否在圖形內。
那假如我的圖形可能有變形、放大、偏移、旋轉的需求呢？你的這個isPointInSide怎么處理？
這個我答不出來，據面試官提示，好像有相應的API處理變形、旋轉、放大等等之后的位置映射關系。
那個這個canvas的點擊事件，點擊的時候怎么樣快速的從這5000個圓中找到你點擊的那個圓（不完全遍歷5000個節點）？
可以通過預查找的形式，當鼠標劃過的時候預先查找到鼠標附近的一些節點，當點擊的時候在從這些預先篩選好的節點里查找點擊下來的節點，當然這個方法的前提是不能影響js主線程的執行，必須是異步的形式。
那你用過@antv/g6，里面有一個tree，說說你大學時候接觸到的tree的數據結構是怎么實現的？
畢業一年多，tree的結構大概忘記了，我當時是這么回答的：
大學使用的是C++學的數據結構，是用指針的形式，首先有一個根節點，根節點里有一個指針數組指向它的所有子節點，然后每一個子節點也是，擁有著子節點的指針數組，一層一層往下，直到為葉子節點，指針數組指向為空。
還記得二叉樹嗎？描述二叉樹的幾種遍歷方式？
先序遍歷：若二叉樹非空，訪問根結點，遍歷左子樹，遍歷右子樹。
中序遍歷：若二叉樹非空，遍歷左子樹；訪問根結點；遍歷右子樹。
后序遍歷：若二叉樹非空，遍歷左子樹；遍歷右子樹；訪問根結點。
所有遍歷是以遞歸的形似，直到沒有子節點。
說說你記得的所有的排序，他們的原理是什么？
冒泡排序：雙層遍歷，對比前后兩個節點，如果滿足條件，位置互換，直到遍歷結束。
快速排序：去數組中間的那一個數，然后遍歷所有數，小于該數的push到一個數組，大于該數的push到另外一個數組，然后遞歸去排序這兩個數組，最后將所有結果連接起來。
選擇排序：聲明一個數組，每次去輸入數組里面找數組中的最大值或者最小值，取出來后push到聲明的數組中，直到輸入數組為空。
說一下你覺得你做過的最復雜的項目？中間遇到的困難，以及你是怎么解決的？
面試官：我這邊問題差不多問完了，你還有什么問題？
我：很驚訝今天全都是問可視化相關的，沒怎么問js，css，html。
面試官：那我們繼續吧
我：。。。
那給我介紹一下react吧（面試官是做可視化開發的，根本不懂react）
以前我們沒有jquery的時候，我們大概的流程是從后端通過ajax獲取到數據然后使用jquery生成dom結果然后更新到頁面當中，但是隨著業務發展，我們的項目可能會越來越復雜，我們每次請求到數據，或則數據有更改的時候，我們又需要重新組裝一次dom結構，然后更新頁面，這樣我們手動同步dom和數據的成本就越來越高，而且頻繁的操作dom，也使我我們頁面的性能慢慢的降低。
這個時候mvvm出現了，mvvm的雙向數據綁定可以讓我們在數據修改的同時同步dom的更新，dom的更新也可以直接同步我們數據的更改，這個特定可以大大降低我們手動去維護dom更新的成本，mvvm為react的特性之一，雖然react屬于單項數據流，需要我們手動實現雙向數據綁定。
有了mvvm還不夠，因為如果每次有數據做了更改，然后我們都全量更新dom結構的話，也沒辦法解決我們頻繁操作dom結構(降低了頁面性能)的問題，為了解決這個問題，react內部實現了一套虛擬dom結構，也就是用js實現的一套dom結構，他的作用是講真實dom在js中做一套緩存，每次有數據更改的時候，react內部先使用算法，也就是鼎鼎有名的diff算法對dom結構進行對比，找到那些我們需要新增、更新、刪除的dom節點，然后一次性對真實DOM進行更新，這樣就大大降低了操作dom的次數。
那么diff算法是怎么運作的呢，首先，diff針對類型不同的節點，會直接判定原來節點需要卸載并且用新的節點來裝載卸載的節點的位置；針對于節點類型相同的節點，會對比這個節點的所有屬性，如果節點的所有屬性相同，那么判定這個節點不需要更新，如果節點屬性不相同，那么會判定這個節點需要更新，react會更新并重渲染這個節點。
設計之初是主要負責UI層的渲染，雖然每個組件有自己的state，state表示組件的狀態，當狀態需要變化的時候，需要使用setState更新我們的組件，但是，我們想通過一個組件重渲染它的兄弟組件，我們就需要將組件的狀態提升到父組件當中，讓父組件的狀態來控制這兩個組件的重渲染，當我們組件的層次越來越深的時候，狀態需要一直往下傳，無疑加大了我們代碼的復雜度，我們需要一個狀態管理中心，來幫我們管理我們狀態state。
這個時候，redux出現了，我們可以將所有的state交給redux去管理，當我們的某一個state有變化的時候，依賴到這個state的組件就會進行一次重渲染，這樣就解決了我們的我們需要一直把state往下傳的問題。redux有action、reducer的概念，action為唯一修改state的來源，reducer為唯一確定state如何變化的入口，這使得redux的數據流非常規范，同時也暴露出了redux代碼的復雜，本來那么簡單的功能，卻需要完成那么多的代碼。
后來，社區就出現了另外一套解決方案，也就是mobx，它推崇代碼簡約易懂，只需要定義一個可觀測的對象，然后哪個組價使用到這個可觀測的對象，并且這個對象的數據有更改，那么這個組件就會重渲染，而且mobx內部也做好了是否重渲染組件的生命周期shouldUpdateComponent，不建議開發者進行更改，這使得我們使用mobx開發項目的時候可以簡單快速的完成很多功能，連redux的作者也推薦使用mobx進行項目開發。但是，隨著項目的不斷變大，mobx也不斷暴露出了它的缺點，就是數據流太隨意，出了bug之后不好追溯數據的流向，這個缺點正好體現出了redux的優點所在，所以針對于小項目來說，社區推薦使用mobx，對大項目推薦使用redux。
假如我一個組件有一個狀態count為1，然后我在componentDidMount()里面執行執行了兩次this.setState({count: this.state.count++})，然后又執行了兩次setTimeout(() => { this.setState({count: this.state.count++}) }, 0)，最后count為多少？為什么？
為4，因為第二次執行setState的時候，取不到第一次this.state.count++的結果，react在一輪生命周期結束后才會更新內部的state，如果在一輪生命周期內多次使用了setState，react內部會有一個字段isBatchUpdate標識本次更新為批量更新，然后在最后render的時候將所有setState的結果提交到state中，一次性進行更新，并且把isBatchUpdate這個字段設置為false。
針對于兩次setTimeout，js引擎會把這兩個setState丟到事件隊列中，等待js空閑了去執行，而我們的渲染函數render是同步執行的（react16版本默認沒有開啟異步渲染），所以等我們render執行完全，也就是我們的state被同步完后，在取事件隊列里面的setState進行執行，setTimeout的第二個setState也是一樣的，所以最后結果是4。
說一下你覺得你做過的最值得你說的吧
最后
這幾輪面試的面試官都非常和藹好交流，百度的五輪面試不知道過了沒有，只記得五面的面試官說，你稍等一下，我去問一下其他人對你還有什么其他要求，然后過了一會兒HR就喊我先回去了，叫我等HR面的消息，如果沒通過，也不會在聯系我了，已經過了四天了，但愿后面有消息吧。然后有贊、螞蟻金服的兩個一面都過了，因為每次面完試面試官問我還有什么問題嗎？我都會詢問一下本次面試面試官對我的評論是啥。
