Vue.js定義是一個“數據驅動漸進式”框架，學習它的時候，其中很多東西都能讓我們眼前一亮（當然react、angular也各有千秋），比如說數據雙向綁定、組件路由模塊化、靈活的指令、全家桶等等。工作有幾年了，一開始用Vue總感覺自己好像在照葫蘆畫瓢，然后看文檔啊，記筆記啊，覺得自己成長很快！不錯，我還是一個優秀好學的好青年！嘿，后面慢慢用Vue，用熟悉了，使用Vue框架快速開發一個普通項目，滿足產品業務，摸魚！下班！回家！躺平！舒服！（開發小伙伴懂的都懂，不懂的，沒辦法接著照葫蘆畫瓢咯！）

       一直到有一天，我偶遇一個前端大神，聊著聊著，他突然問了我一句：“你Vue用的怎么樣啊？”我心想：“嘿，這問到我的強項上來了！”“Vue框架啊！我熟！”我說，然后我就嗶哩嗶哩說了半天我做了哪些哪些項目，多么多么豐富的經驗。

       大神用奇怪的眼神，略帶鄙夷的打量了我一下，說：“我感覺，你只是會用這個框架，這個在咱們業界叫工具人，就是為了滿足業務而產生的快速生產工具，真正的程序員不是這樣的！”

       嘿，我堂堂七尺男兒，被這樣鄙夷，文無第一，武無第二！反擊！說到：“Vue的底層源代碼原理，Vue3的新技術，我都研究過！”然后就介紹了一些晦澀的技術術語！心想：“裝逼？！嘿，哥們我混跡程序員的圈子好歹也有幾年了，想就這樣戰勝我？沒門！大風大浪都經過了，還能在這小場面翻船？！”大神處變不驚，稍微正視了我一下，然后說道：“其實，能夠靜下心來看這些底層原理，確實已經不錯了！至少比很多很多所謂的前端開發工程師強了不少了！”

       我的嘴角揚起了微微笑，卻聽到了大神的靈魂拷問：“Vue2的本質是什么？為什么這么多企業在業務中使用？為什么有了Vue3？Vue3在企業中什么地方該用？什么地方不該用？TypeScript很不錯，你在項目中使用了多少？你覺得該不該用？如果說一個項目，你如何精準的判斷得出來你到底該使用Vue2好呢？還是Vue3？還是React？或者是jQuery？甚至是原生JavaScript？”大神頓了頓，說出了一句絕唱：“其實，技術永遠都是折中的解決方案，沒有什么絕對的好，也沒有什么絕對的不好，互聯網上一知半解的小孩子們總是在評價好壞，其實本質上是沒有價值的！找找自我存在感罷了！”

       說完，大神淡淡的吐了一口煙，沉靜的眼神，加上他在技術圈里的故事，我感覺，這句話不像是在“吹牛裝逼”了！那一刻，我似乎看到了，真正的技術大神理解的是格局，這些五花八門的框架，只是為了滿足他解決問題的一個工具而已，最難的是！你能夠做出最正確的決策，到底使用什么工具來事半功倍的解決問題！我就對自己有了一個靈魂發問：“Vue這個前端框架我到底學會了嗎？”

       一直到多年成長以后，回頭看看走過的路！見過山，見過水后，我不得不承認，至少在當初大神靈魂拷問我的那個時候，我其實真的還是一個工具人，充其量是一個花了一點點小心思，為了裝逼而強忍著讀了幾行源代碼的小前端。到了今天，我再來回答回答當初大神問到的這些問題，希望有更多的小伙伴指導一二，共同成長！

       靈魂拷問一：“Vue2的本質是什么？為什么這么多企業在業務中使用？”

       “明知故問，Vue2不就是一個數據驅動漸進式框架嗎？數據驅動你不懂？漸進式你不理解？全家桶你不會用？”沒錯，如果是當年的我內心是這樣反擊的！可是，實際上，今天我來說另外一種答案，小伙伴們來評判一下，這兩個答案有啥區別？

       首先，我想說的是，Vue其本質是一個『構造函數』（工廠函數？構造函數？不懂？基礎不牢地動山搖啊，小伙伴！）。當我們使用new關鍵字實例化出來一個Vue對象的時候（構造函數中new這個關鍵字都干了啥？不知道？趕緊去看看吧，為啥這么多面試題都會問到這個？），其原型、原型鏈上聲明的屬性和方法會根據面向對象編程思想（OOP不知道是啥？天啦，趕緊去學習基礎吧！~）傳入的參數，構建我們需要的對象，我們所有的操作，其本質上來講就是在操作這個對象的屬性改變和方法調用，不信，你 console一下實例化出來的Vue對象瞅瞅，如下圖：

       為什么我第一個問題要說這個Vue實例對象呢？首先，Vue的功能強大，作者設計思路之新穎全面，很多初學它的人會本能的覺得好像和原生的JavaScript沒有多大關系，其實不然，其本質就還是一個工廠構造函數實例化出來的對象，只不過是一個龐大了點的對象，這是n個人智慧結晶的積累。這里面富含了大量的編程思維，還有扎實的理論功底，這也是我們前端工程師技術方向的終極道路：核心架構師，不過成長到這個地步的人，需要的不僅僅是學習，更需要有科研環境的團隊氛圍。

       接著，來說是，這些編程思維中最核心的三個基點。一是：雙向數據綁定，老生常談，你肯定知道就是：Object.defineProperty(obj, prop, descriptor)，沒錯，確實如此，見下圖：

       此時此刻小伙伴們心里肯定在想：“切！沒啥難的，這段代碼很好理解嘛！Show啥？裝逼！”確實有裝逼的嫌疑，不過，這個邏輯往下的延伸叫“觀察者模式”編程思想，那就博大精深了，此處省略一萬字。。。。。。

       接著我們來說第二個基點，靈活的Vue指令讓我們快速的使用，這個靈活的指令是如何實現的呢？這個時候，我們就需要對代碼本身有深刻的理解了，比如說：匯編原理。我們所寫的所有的代碼，其本質上來講是一段字符串文本，Vue基于Node本地服務器（腳手架Webpack幫我們干的事情）來進行運行的。OK，這個腳手架，都干了啥呢？怎么干的呢？其實，正如我上面提到的匯編原理，編譯！編譯這件事才是核心！Node服務器讀到了這些文件中的字符串，然后使用正則表達式進行匹配，匹配后基于Webpack的流處理機制，一步一步的解析成為我們瀏覽器最終能夠解析的結果純純的HTML、CSS和JavaScript。當然，基本上都是使用JavaScript來體現HTML、CSS的，為什么呢？因為，SPA應用啊，組件路由模塊化啊！OK，這里，也很博大精深啊，此處再省略一萬字....

       最后，我們來說說第三個基點，數據驅動的深層次理解，當然，小伙伴們第一時間肯定會想到diff算法，批量按需更新，再深入一點的小伙伴們肯定也能想到深、淺拷貝。而我想說的是數據結構和算法的編程基礎能力。堆內存、棧內存是個啥？數據是如何在其中存儲的？（你以為面試官在問你JavaScript有哪些數據類型嗎？No，面試官更想聽你說，為什么會有這些數據類型！）算法？算法是個啥？快速冒泡排個序？OK，這個是算法！樹形結構的內存索引存儲模式，哈夫曼樹的最優解？DOM更新的批量按需渲染機制是為啥？天啦~說實話，我對這些也只能是一知半解，但是，很多小伙伴，對這些似乎從未感覺存在過！這就太可怕了！

       第二個小問題，為什么這么多企業會選擇Vue2來做開發？是的很簡單，因為她簡單、自然、美麗、大方、可愛，呸呸！我在說編程，不是在說妹子！想多了！實際上，簡答的一句話就能說清，因為Vue2的程序員學習成本低，好招工，價格便宜，開發效率也高！節約成本！小伙伴們又吐槽了：“這！這就想打發我？！”且不要著急，諸位小伙伴且聽我來回答大神當初提到的第二個靈魂拷問。

       靈魂拷問二：為什么有了Vue3？Vue3在企業中什么地方該用？什么地方不該用？

       在回答這個問題之前，我先說到我們程序員基礎課中經常提到的兩個關鍵字：內聚、耦合！這是程序設計的規范，高內聚，低耦合！為什么出現了Vue3？其實從本質上來講就是為了解決這個問題！那么問題來了，Vue2的內聚哪里低了？耦合哪里高了？當然這里我實在不想提到什么Composition API、Options API，事實上，我已經提了！事實上，早在 Vue3 源碼公布之前，Vue 官方已經透露了代表下一代 Vue 技術的 Vue3 將采取的新的接口使用方式。這種新的方式叫做 Composition API （組合式 API）。而與之相對應的經典 API 也是我們所熟知的 Vue 使用方式叫做 Options API（選項式 API）或 Options-based API（基于選項的 API）。

       在經典的 Options API 中，我們使用一個具有 data, methods 等「選項」的 JS 對象來定義一個頁面或者組件。這種簡單直接的方式，在應用早期階段，代碼和業務邏輯較簡單時，非常的友好親民，這也是 Vue 學習門檻較低而廣受開發者親昵的的一個因素。

       但是，有過開發大型 Vue 應用的開發者應該心有體會。當頁面的邏輯越來越多時，我們的組件將變得冗長復雜。很多本可以復用的邏輯和代碼，你很難有一種使用起來非常舒適的方式來復用。比如：在 Vue2 中，組件邏輯和代碼復用最常用的方式是混入mixin，這雖然是一種可行的方式，但是這種方式顯然從出生和 Vue 框架緊密耦合（看到了吧？這是不是高耦合了？反程序設計基礎規范了吧！）。當你想要將一個框架無區別的普通 JS 函數或者對象復用到 Vue2 開發的組件中時，你發現一切都是那么的不優雅。

       基于滿足在開發大型 Vue 應用中更優雅地復用已有代碼的需求催生下，Vue3 Composition API 似乎是順勢而為，并且勢在必得。OK，篇幅已經很長了！我也累了，下面還有好多問題待解答呢，先解釋這么多了，其實，坦白說，想說的很多，此處再省略一萬字...，哈哈，小伙伴啊，這些都是為了讓你看破迷霧，看到山的一角，看到了，走下去就夠了唄！

       Vue3在企業中什么地方該用？什么地方不該用？說實話，沒有固定的答案，因為你腦袋一熱，認為這個項目很復雜，我要大干！就用Vue3！重構一下！事實上，Vue2真的很親民，雖然不親程序設計規范，但是，省人省事省錢啊！當然，如果，你就是為了欺負老板不懂技術，延長工期，show技術肌肉，多掙點錢，多掙點面子，就當我沒有說過上面的話！這已經不是技術了，這是人性，辦公室政治咯！

       靈魂拷問三：TypeScript很不錯，你在項目中使用了多少？你覺得該不該用？其實這個答案，可以用兩個字來回答，信不？！答案，“同上”！好啦，還是先聊技術的本源，再聊人性的小九九！

       TypeScript其本質上講核心是為了解決JavaScript編程語言弱類型這個問題而產生的，為了有效的解決程序變量在傳來傳去的過程中不嚴謹的問題！程序嘛，肯定要非常嚴謹才行啊！畢竟，咱們JavaScript語言現在熱門啊，是程序語言中的一哥啊！

       那么，TypeScript是如何解決這個嚴謹的問題呢？兩個方面，官方也是這樣講的：TypeScript 本質上是向 JavaScript 語言添加了「可選的靜態類型」和「基于類的面向對象」編程，它相當于是JavaScript的超集。

       說實話，TypeScript 的官方文檔非常非常適合前端開發者進階學習使用，這個非常有助于我們突破我們的技術壁壘，建議大家一定要細細研讀，不同階段的開發者研讀文檔的感覺各有千秋，但都大有收獲。

       我只能說這么多了！因為，前端開發者如果沒有深厚的編程經驗，真的，很難精準的理解什么是面向對象編程！什么是數據類型嚴謹！最后，來說說項目中使用TS，小兄弟啊！小項目，不復雜的項目，真的可以不用！都這樣內卷了，何必呢？！就為了一個最簡單的類型約束，show幾個新的語法特性，來幾個泛型編程，你要知道，為了解析你這個玩意，Node的Webpack會做多少工作？代碼增加多少？真的，除非是數據嚴謹要求極高，項目業務邏輯極其復雜的項目，能不卷就不要卷了！當然，補充一句，我也卷過TypeScript，并且卷過很多，勞民傷財的事情干多了，后面回頭看看，真的是傷人傷己！

       靈魂拷問四：如果說一個項目，你如何精準的判斷得出來你到底該使用Vue2好呢？還是Vue3？還是React？或者是jQuery？甚至是原生JavaScript？

       看山是山，看水是水吧！不濃妝艷抹、東施效顰的做作！更不，不懂裝懂，自欺欺人的蠻干！技術永遠是業務折中的解決方案，這個是真的！既然是折中的解決方案，核心就在于利弊權衡上！

       如果，這個站點對SEO有強關聯并且前后端很難分離，你非要使用什么Vue or React，那就不對了！jQuery基于DOM編程一定是你的最佳選擇！如果這個前后端能分離，但是SEO強要求，那么你要看看你團隊小伙伴們的實力如何！Nuxt SSR玩的溜不溜！學習成本高不高！如果不溜，小伙伴們技術水平高度不夠，那就還是用jQuery，如果小伙伴們技術水平夠，那就使用SSR，這里需要補充一句是：SSR必須要有后端開發的相關經驗，你告訴我，我看過文檔！去死！坑人！要么你老板去死！你坑死他！

       如果是大型復雜項目，具有非常多的業務模塊復用邏輯，并且數據通信邏輯復雜，那么你可以使用Vue3 or React Hooks，這個沒毛病，大量的業務模塊被復用，又復用的不一樣，再不用這個玩意，團隊之間的代碼強耦合，那就太難受了！單溝通成本就高的讓你瘋掉！

       原生JavaScript？Ok，如果你是涉及到最新的前沿課題，比如區塊鏈客戶端邏輯封裝，或者你在大廠的一個框架研究中心，你可以用，小打小鬧，還是小心為上 ！你真以為原生JavaScript很easy？沒有真正打通任督二脈的功力，走火入魔是常有的事情！

       Vue前端框架我到底學會了嗎？沒有！我才剛剛開始！千言萬語，其實，想跟小伙伴們說的是這樣四個字：“打好基礎”。怎么樣打好基礎？匯編原理、網絡工程、數據結構、基礎算法、開發模式等等，這些大學里看似無用的書中，會有你想要的答案的！

上一篇

千鋒長沙前端培訓分享之高級前端面試題整理

下一篇

千鋒長沙前端培訓分享之使用jsDoc提升開發效率