總的來說，Vue3在底層原理和實際業務發展上都取得了長足的進步。
使用proxy代替之前的Object.defineProperty的API具有更好的性能，同時也解決了vue在處理對象和數組方面的缺陷。在diff算法中，使用了靜態標記方法，大大提高了Vue的執行效率。
在使用層面，我們從options Api轉變為composition Api，慢慢地在實際業務中，我們放棄了原來孤立的編寫方式如data、methods和computed。Compositon Api更專註於相關業務的聚合。
全面支持TypeScript，類型驗證也成為Vue3中大型項目未來開發的質量保障，這也是大勢所趨——前端的未來是TypeScript！
compositon Api的精髓體現在代碼中，它是壹個設置函數。在此設置功能中，返回的數據將用於組件的模板中。這個返回的對象，在壹定程度上代表了之前vue2中的數據屬性。
這時，對於大多數初學者來說，可能會有疑問，那麽我可以定義options Api的編寫嗎，例如data、computed、watch、methods等等。
這裏我需要明確的是，Vue3完全兼容Vue2的這個options Api的編寫方式，但從概念上來說，更推薦用setup的方式編寫我們的組件。
原因如下:Vue3的存在本身就是為了解決Vue2的問題。Vue2的問題是缺乏聚合會導致代碼越來越臃腫！設置的方式可以將數據、方法邏輯和依賴關系放在壹起，更便於維護。
換句話說，在未來，我們應該盡量不要單獨編寫數據、計算、觀察、方法等。並不是Vue3不支持，而是與Vue3的理念相悖。
組件屬性，即組件的子組件，在Vue2和Vue3之間幾乎沒有區別。Vue2的使用方法仍然與Vue 3相同。
就功能而言，ref和reactive都是響應式數據！
在語法層面上，兩者是有區別的。ref定義的響應數據需要以【data】的形式進行更改。價值；由反應需求【數據】定義的數據。【權限】更改數據。
但在應用層面，仍存在差異。壹般來說，我們使用ref來定義單壹常見數據類型的響應。在表單場景中，描述表單key:value的場景，並使用reactive；在某些場景中，模塊的壹組數據通常以反應的方式定義數據。
那麽，對象必須由反應性定義嗎？其實不是的。壹切都可以做到。根據自己的業務場景，具體問題具體分析！Ref強調壹個數據的值的變化，而reactive強調定義對象的某個屬性的變化。
Vue3中的周期函數單獨使用，使用方式如下:
在Vue2中，實際上可以通過這個直接獲得。$store，但在Vue3中，沒有這樣的概念，用法如下:
在Vue2中，路由由此編程。$router，但在Vue3中，它的用法如下:
merchant.ts
這部分內容，準確地說，是TS的內容，但它與Vue3項目的開發密切相關，所以如果我們真的要使用Vue3，我們還是要了解TS的使用方法。
但是，在這壹部分中，我不會介紹TS的基本語法，主要是如何在業務場景中組織TS。
在公共接口請求中，我們通常使用TS來定義數據請求、數據請求的req類型和數據請求的res類型。