總的來說，Vue3無論是底層原理還是實際業務發展都取得了很大的進步。
用proxy代替之前的Object.defineProperty的API，性能更好，也解決了vue在處理對象和數組方面的缺陷。在diff算法中，采用了靜態標記的方法，大大提高了Vue的執行效率。
在使用層面，我們從options Api變成了composition Api，慢慢的在實際業務中，我們拋棄了原來數據、方法、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的理念。
Components屬性，即壹個組件的子組件，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類型。