Hello，大家好，我是 Sunday。

最近一位同學在學習 vue3 源碼的時候，把 vue 3 的大部分核心邏輯都整理到了腦圖之中：

整理的內容非常詳細。應該會對所有還在學習 vue3 源碼的同學都有所幫助。所以分享給大家！

那么今天，咱們就借助這位同學的腦圖作為契機，來為大家捋一捋 【Vue3 框架設計原理】（看完設計原理之后，再看腦圖收獲會更大哦~）

01：前言

在了解 Vue3 框架設計之前，我們需要做兩件事情，而這兩件事情也是今天的主要內容。

1. 我們需要同步并明確一些詞匯的概念，比如：聲明式、命令式、運行時、編譯時...。這些詞匯將會在后面的框架設計中被經常涉及到。
2. 我們需要了解一些關于 前端框架 的一些基礎的概念。框架的設計原則，開發者開發體驗原則。以此來幫助大家解決一些固有的疑惑，從而揭開 vue 神秘的面紗。

那么準備好了？

我們開始吧！

02：編程范式之命令式編程

針對于目前的前端開發而言，主要存在兩種 編程范式：

1. 命令式編程
2. 聲明式編程

這兩種 范式 一般是相對來去說的。

命令式

那么首先我們先來說什么叫做 命令式。

具體例子：

張三的媽媽讓張三去買醬油。

那么張三怎么做的呢？

1. 張三拿起錢
2. 打開門
3. 下了樓
4. 到商店
5. 拿錢買醬油
6. 回到家

以上的流程詳細的描述了，張三在買醬油的過程中，每一步都做了什么。那么這樣一種：詳細描述做事過程 的方式就可以被叫做 命令式。

那么如果把這樣的方式放到具體的代碼實現之中，又應該怎么做呢？

我們來看以下這樣的一個事情：

在指定的 div 中展示 “hello world”

那么如果想要完成這樣的事情，通過命令式的方式我們如何實現呢？

我們知道命令式的核心在于：關注過程。

所以，以上事情通過命令式實現則可得出以下邏輯與代碼：

// 1. 獲取到指定的 div
const divEle = document.querySelector('#app')
// 2. 為該 div 設置 innerHTML 為 hello world
divEle.innerHTML = 'hello world'

該代碼雖然只有兩步，但是它清楚的描述了：完成這件事情，所需要經歷的過程

那么假如我們所做的事情，變得更加復雜了，則整個過程也會變得更加復雜。

比如：

為指定的 div 的子元素 div 的子元素 p 標簽，展示變量 msg

那么通過命令式完成以上功能，則會得出如下邏輯與代碼：

// 1. 獲取到第一層的 div
const divEle = document.querySelector('#app')
// 2. 獲取到它的子 div
const subDivEle = divEle.querySelector('div')
// 3. 獲取第三層的 p
const subPEle = subDivEle.querySelector('p')
// 4. 定義變量 msg
const msg = 'hello world'
// 5. 為該 p 元素設置 innerHTML 為 hello world
subPEle.innerHTML = msg

那么通過以上例子，相信大家可以對命令式的概念有了一個基礎的認識。

最后做一個總結，什么叫做命令式呢？

命令式是：關注過程 的一種編程范式，他描述了完成一個功能的 詳細邏輯與步驟。

03：編程范式之聲明式編程

當了解完命令式之后，那么接下來我們就來看 聲明式 編程。

針對于聲明式而言，大家其實都是非常熟悉的了。

比如以下代碼，就是一個典型的 聲明式 ：

<div>{{ msg }}</div>

對于這個代碼，大家是不是感覺有些熟悉？

沒錯，這就是 Vue 中非常常見的雙大括號語法。所以當我們在寫 Vue 模板語法 的時候，其實一直寫的就是 聲明式 編程。

那么聲明式編程具體指的是什么意思呢？

還是以剛才的例子為例：

張三的媽媽讓張三去買醬油。

那么張三怎么做的呢？

1. 張三拿起錢
2. 打開門
3. 下了樓
4. 到商店
5. 拿錢買醬油
6. 回到家

在這個例子中，我們說：張三所做的事情就是命令式。那么張三媽媽所做的事情就是 聲明式。

在這樣一個事情中，張三媽媽只是發布了一個聲明，她并不關心張三如何去買的醬油，只關心最后的結果。

所以說，所謂聲明式指的是：不關注過程，只關注結果 的范式。

同樣，如果我們通過代碼來進行表示的話，以下例子：

為指定的 div 的子元素 div 的子元素 p 標簽，展示變量 msg

將會得出如下代碼：

<div id="app">
  <div>
    <p>{{ msg }}</p>
  </div>
</div>

在這樣的代碼中，我們完全不關心 msg 是怎么被渲染到 p 標簽中的，我們所關心的只是：在 p 標簽中，渲染指定文本而已。

最后做一個總結，什么叫做聲明式呢？

聲明式是：關注結果 的一種編程范式，他 并不關心 完成一個功能的 詳細邏輯與步驟。（注意：這并不意味著聲明式不需要過程！聲明式只是把過程進行了隱藏而已！）

04：命令式 VS 聲明式

那么在我們講解完成 命令式 和 聲明式 之后，很多同學肯定會對這兩種編程范式進行一個對比。

是命令式好呢？還是聲明式好呢？

那么想要弄清楚這個問題，那么我們首先就需要先搞清楚，評價一種編程范式好還是不好的標準是什么？

通常情況下，我們評價一個編程范式通常會從兩個方面入手：

1. 性能
2. 可維護性

那么接下來我們就通過這兩個方面，來分析一下命令式和聲明式。

性能

性能一直是我們在進行項目開發時特別關注的方向，那么我們通常如何來表述一個功能的性能好壞呢？

我們來看一個例子：

為指定 div 設置文本為 “hello world”

那么針對于這個需求而言，最簡單的代碼就是：

div.innerText = "hello world" // 耗時為：1

你應該找不到比這個更簡單的代碼實現了。

那么此時我們把這個操作的 耗時 比作 ：1 。（PS：耗時越少，性能越強）

然后我們來看聲明式，聲明式的代碼為：

<div>{{ msg }}</div>  <!-- 耗時為：1 + n -->
<!-- 將 msg 修改為 hello world -->

那么：已知修改text最簡單的方式是innerText  ，所以說無論聲明式的代碼是如何實現的文本切換，那么它的耗時一定是 > 1 的，我們把它比作 1 + n（對比的性能消耗）。

所以，由以上舉例可知：命令式的性能 > 聲明式的性能

可維護性

可維護性代表的維度非常多，但是通常情況下，所謂的可維護性指的是：對代碼可以方便的 閱讀、修改、刪除、增加 。

那么想要達到這個目的，說白了就是：代碼的邏輯要足夠簡單，讓人一看就懂。

那么明確了這個概念，我們來看下命令式和聲明式在同一段業務下的代碼邏輯：

// 命令式
// 1. 獲取到第一層的 div
const divEle = document.querySelector('#app')
// 2. 獲取到它的子 div
const subDivEle = divEle.querySelector('div')
// 3. 獲取第三層的 p
const subPEle = subDivEle.querySelector('p')
// 4. 定義變量 msg
const msg = 'hello world'
// 5. 為該 p 元素設置 innerHTML 為 hello world
subPEle.innerHTML = msg

// 聲明式
<div id="app">
  <div>
    <p>{{ msg }}</p>
  </div>
</div>

對于以上代碼而言，聲明式 的代碼明顯更加利于閱讀，所以也更加利于維護。

所以，由以上舉例可知：**命令式的可維護性 < 聲明式的可維護性 **

小結一下

由以上分析可知兩點內容：

1. 命令式的性能 > 聲明式的性能
2. 命令式的可維護性 < 聲明式的可維護性

那么雙方各有優劣，我們在日常開發中應該使用哪種范式呢？

想要搞明白這點，那么我們還需要搞明白更多的知識。

05：企業應用的開發與設計原則

企業應用的設計原則，想要描述起來比較復雜，為什么呢？

因為對于 不同的企業類型（大廠、中小廠、人員外包、項目外包），不同的項目類型（前臺、中臺、后臺）來說，對應的企業應用設計原則上可能會存在一些差異。

所以我們這里所做的描述，會拋棄一些細微的差異，僅抓住核心的重點來進行闡述。

無論什么類型的企業，也無論它們在開發什么類型的項目，那么最關注的點無非就是兩個：

1. 項目成本
2. 開發體驗

項目成本

項目成本非常好理解，它決定了一個公司完成“這件事”所付出的代價，從而直接決定了這個項目是否是可以盈利的（大廠的燒錢項目例外）。

那么既然項目成本如此重要，大家可以思考一下，決定項目成本的又是什么？

沒錯！就是你的 開發周期。

開發周期越長，所付出的人員成本就會越高，從而導致項目成本變得越高。

通過我們前面的分析可知，聲明式的開發范式在 可維護性 上，是 大于 命令式的。

而可維護性從一定程度上就決定了，它會使項目的：開發周期變短、升級變得更容易 從而大量節約開發成本。

所以這也是為什么 Vue 會變得越來越受歡迎的原因。

開發體驗

決定開發者開發體驗的核心要素，主要是在開發時和閱讀時的難度，這個被叫做：心智負擔。

心智負擔可以作為衡量開發難易度的一個標準，心智負擔高則證明開發的難度較高，心智負擔低則表示開發的難度較低，開發更加舒服。

那么根據我們之前所說，聲明式的開發難度明顯低于命令式的開發難度。

所以對于開發體驗而言，聲明式的開發體驗更好，也就是 心智負擔更低。

06：為什么說框架的設計過程其實是一個不斷取舍的過程？

Vue 作者尤雨溪在一次演講中說道：框架的設計過程其實是一個不斷取舍的過程 。

這代表的是什么意思呢？

想要搞明白這個，那么再來明確一下之前說過的概念：

1. 命令式的性能 > 聲明式的性能
2. 命令式的可維護性 < 聲明式的可維護性
3. 聲明式的框架本質上是由命令式的代碼來去實現的
4. 企業項目開發時，大多使用聲明式框架

當我們明確好了這樣的一個問題之后，那么我們接下來來思考一個問題：框架的開發與設計原則是什么呢？

我們知道對于 Vue 而言，當我們使用它的是通過 聲明式 的方式進行使用，但是對于 Vue 內部而言，是通過 命令式 來進行的實現。

所以我們可以理解為：Vue 封裝了命令式的邏輯，而對外暴露出了聲明式的接口

那么既然如此，我們明知 命令式的性能 > 聲明式的性能 。那么 Vue 為什么還要選擇聲明式的方案呢？

其實原因非常的簡單，那就是因為：命令式的可維護性 < 聲明式的可維護性 。

為指定的 div 的子元素 div 的子元素 p 標簽，展示變量 msg

以這個例子為例。

對于開發者而言，不需要關注實現過程，只需要關注最終的結果即可。

而對于 Vue 而言，他所需要做的就是：封裝命令式邏輯，同時 盡可能的減少性能的損耗！它需要在 性能 與 可維護性 之間，找到一個平衡。從而找到一個 可維護性更好，性能相對更優 的一個點。

所以對于 Vue 而言，它的設計原則就是：在保證可維護性的基礎上，盡可能的減少性能的損耗。

那么回到我們的標題：為什么說框架的設計過程其實是一個不斷取舍的過程？

答案也就呼之欲出了，因為：

我們需要在可維護性和性能之間，找到一個平衡點。在保證可維護性的基礎上，盡可能的減少性能的損耗。

所以框架的設計過程其實是一個不斷在 可維護性和性能 之間進行取舍的過程

07：什么是運行時？

在 Vue 3 的 源代碼 中存在一個 runtime-core 的文件夾，該文件夾內存放的就是 運行時 的核心代碼邏輯。

runtime-core 中對外暴露了一個函數，叫做 渲染函數render

我們可以通過 render 代替 template 來完成 DOM 的渲染：

有些同學可能看不懂當前代碼是什么意思，沒有關系，這不重要，后面我們會詳細去講。

<head>
  <meta charset="UTF-8">
  <title>Document</title>
  <script src="https://unpkg.com/vue@3.2.36/dist/vue.global.js"></script>
</head>

<body>
  <div id="app"></div>
</body>

<script>
  const { render, h } = Vue
  // 生成 VNode
  const vnode = h('div', {
    class: 'test'
  }, 'hello render')

  // 承載的容器
  const container = document.querySelector('#app')

  // 渲染函數
  render(vnode, container)
</script>

我們知道，在 Vue 的項目中，我們可以通過 tempalte 渲染 DOM 節點，如下：

<template>
	<div class="test">hello render</div>
</template>

但是對于 render 的例子而言，我們并沒有使用 tempalte，而是通過了一個名字叫做 render 的函數，返回了一個不知道是什么的東西，為什么也可以渲染出 DOM 呢？

帶著這樣的問題，我們來看：

我們知道在上面的代碼中，存在一個核心函數：渲染函數 render，那么這個 render 在這里到底做了什么事情呢？

我們通過一段代碼實例來去看下：

假設有一天你們領導跟你說：

我希望根據如下數據：

渲染出這樣一個 div：

{
 type: 'div',
 props: {
  class: test
 },
 children: 'hello render'
}

<div class="test">hello render</div>

那么針對這樣的一個需求你會如何進行實現呢？大家可以在這里先思考一下，嘗試進行一下實現，然后我們再繼續往下看..........

那么接下來我們根據這個需求來實現以下代碼：

<script>
  const VNode = {
    type: 'div',
    props: {
      class: 'test'
    },
    children: 'hello render'
  }
  // 創建 render 渲染函數
  function render(vnode) {
    // 根據 type 生成 element
    const ele = document.createElement(vnode.type)
    // 把 props 中的 class 賦值給 ele 的 className
    ele.className = vnode.props.class
    // 把 children 賦值給 ele 的 innerText
    ele.innerText = vnode.children
    // 把 ele 作為子節點插入 body 中
    document.body.appendChild(ele)
  }

  render(VNode)
</script>

在這樣的一個代碼中，我們成功的通過一個 render 函數渲染出了對應的 DOM，和前面的 render 示例 類似，它們都是渲染了一個 vnode，你覺得這樣的代碼真是 妙極了！

但是你的領導用了一段時間你的 render 之后，卻說：天天這樣寫也太麻煩了，每次都得寫一個復雜的 vnode，能不能讓我直接寫 HTML 標簽結構的方式 你來進行渲染呢？

你想了想之后，說：如果是這樣的話，那就不是以上 運行時 的代碼可以解決的了！

沒錯！我們剛剛所編寫的這樣的一個“框架”，就是 運行時 的代碼框架。

那么最后，我們做一個總結：運行時可以利用render 把 vnode 渲染成真實  dom 節點。

08：什么是編譯時？

在剛才，我們明確了，如果只靠 運行時，那么是沒有辦法通過 HTML 標簽結構的方式 的方式來進行渲染解析的。

那么想要實現這一點，我們就需要借助另外一個東西，也就是 編譯時。

Vue 中的編譯時，更準確的說法應該是 編譯器 的意思。它的代碼主要存在于 compiler-core 模塊下。

我們來看如下代碼：

<!DOCTYPE html>
<html lang="en">

<head>
  <meta charset="UTF-8">
  <title>Document</title>
  <script src="https://unpkg.com/vue@3.2.36/dist/vue.global.js"></script>
</head>

<body>
  <div id="app"></div>
</body>

<script>
  const { compile, createApp } = Vue

  // 創建一個 html 結構
  const html = `
    <div class="test">hello compiler</div>
  `
  // 利用 compile 函數，生成 render 函數
  const renderFn = compile(html)

  // 創建實例
  const app = createApp({
    // 利用 render 函數進行渲染
    render: renderFn
  })
  // 掛載
  app.mount('#app')
</script>

</html>

對于編譯器而言，它的主要作用就是：把 template 中的 html 編譯成 render 函數。然后再利用 運行時 通過 render 掛載對應的 DOM。

那么最后，我們做一個總結：編譯時可以把html 的節點，編譯成 render函數

09：運行時 + 編譯時

前面兩小節我們已經分別了解了 運行時 和 編譯時，同時我們也知道了：vue 是一個 運行時+編譯時 的框架！

vue 通過 compiler 解析 html 模板，生成 render 函數，然后通過 runtime 解析 render，從而掛載真實 dom。

那么看到這里可能有些同學就會有疑惑了，既然 compiler 可以直接解析 html 模板，那么為什么還要生成 render 函數，然后再去進行渲染呢？為什么不直接利用 compiler 進行渲染呢？

即：為什么 vue 要設計成一個 運行時+編譯時的框架呢？

那么想要理清楚這個問題，我們就需要知道 dom 渲染是如何進行的。

對于 dom  渲染而言，可以被分為兩部分：

1. 初次渲染 ，我們可以把它叫做 掛載
2. 更新渲染 ，我們可以把它叫做 打補丁

初次渲染

那么什么是初次渲染呢？

當初始 div 的 innerHTML 為空時，

<div id="app"></div>

我們在該 div 中渲染如下節點：

<ul>
 <li>1</li>
 <li>2</li>
 <li>3</li>
</ul>

那么這樣的一次渲染，就是 初始渲染。在這樣的一次渲染中，我們會生成一個 ul 標簽，同時生成三個 li 標簽，并且把他們掛載到 div 中。

更新渲染

那么此時如果 ul 標簽的內容發生了變化：

<ul>
 <li>3</li>
 <li>1</li>
 <li>2</li>
</ul>

li - 3 上升到了第一位，那么此時大家可以想一下：我們期望瀏覽器如何來更新這次渲染呢？

瀏覽器更新這次渲染無非有兩種方式：

1. 刪除原有的所有節點，重新渲染新的節點
2. 刪除原位置的 li - 3，在新位置插入 li - 3

那么大家覺得這兩種方式哪一種方式更好呢？那么我們來分析一下：

1. 首先對于第一種方式而言：它的好處在于不需要進行任何的比對，需要執行 6 次（刪除 3 次，重新渲染 3 次）dom 處理即可。
2. 對于第二種方式而言：在邏輯上相對比較復雜。他需要分成兩步來做：

1. 對比 舊節點 和 新節點 之間的差異
2. 根據差異，刪除一個 舊節點，增加一個 新節點

那么根據以上分析，我們知道了：

1. 第一種方式：會涉及到更多的 dom 操作
2. 第二種方式：會涉及到 js 計算 + 少量的 dom 操作

那么這兩種方式，哪一種更快呢？我們來實驗一下：

const length = 10000
  // 增加一萬個dom節點，耗時 3.992919921875 ms
  console.time('element')
  for (let i = 0; i < length; i++) {
    const newEle = document.createElement('div')
    document.body.appendChild(newEle)
  }
  console.timeEnd('element')

  // 增加一萬個 js 對象，耗時 0.402099609375 ms
  console.time('js')
  const divList = []
  for (let i = 0; i < length; i++) {
    const newEle = {
      type: 'div'
    }
    divList.push(newEle)
  }
  console.timeEnd('js')

從結果可以看出，dom 的操作要比 js 的操作耗時多得多，即：dom** 操作比 js 更加耗費性能**。

那么根據這樣的一個結論，回到我們剛才所說的場景中：

1. 首先對于第一種方式而言：它的好處在于不需要進行任何的比對，僅需要執行 6 次（刪除 3 次，重新渲染 3 次）dom 處理即可。
2. 對于第二種方式而言：在邏輯上相對比較復雜。他需要分成兩步來做：

對比 舊節點 和 新節點 之間的差異

根據差異，刪除一個 舊節點，增加一個 新節點

根據結論可知：方式一會比方式二更加消耗性能（即：性能更差）。

那么得出這樣的結論之后，我們回過頭去再來看最初的問題：為什么 vue 要設計成一個 運行時+編譯時的框架呢？

答：

1. 針對于 純運行時 而言：因為不存在編譯器，所以我們只能夠提供一個復雜的 JS 對象。
2. 針對于 純編譯時 而言：因為缺少運行時，所以它只能把分析差異的操作，放到 編譯時 進行，同樣因為省略了運行時，所以速度可能會更快。但是這種方式這將損失靈活性（具體可查看第六章虛擬 DOM ，或可點擊 這里 查看官方示例）。比如 svelte ，它就是一個純編譯時的框架，但是它的實際運行速度可能達不到理論上的速度。
3. 運行時 + 編譯時：比如 vue 或 react 都是通過這種方式來進行構建的，使其可以在保持靈活性的基礎上，盡量的進行性能的優化，從而達到一種平衡。

10：什么是副作用

在 vue 的源碼中，會大量的涉及到一個概念，那就 副作用。

所以我們需要先了解一下副作用代表的是什么意思。

副作用指的是：當我們 對數據進行 setter 或 getter 操作時，所產生的一系列后果。

那么具體是什么意思呢？我們分別來說一下：

setter

setter 所表示的是 賦值 操作，比如說，當我們執行如下代碼時 ：

msg = '你好，世界'

這時 msg 就觸發了一次 setter 的行為。

那么假如說，msg 是一個響應性數據，那么這樣的一次數據改變，就會影響到對應的視圖改變。

那么我們就可以說：msg 的 setter 行為，觸發了一次副作用，導致視圖跟隨發生了變化。

getter

getter 所表示的是 取值 操作，比如說，當我們執行如下代碼時：

element.innerText = msg

此時對于變量 msg 而言，就觸發了一次 getter 操作，那么這樣的一次取值操作，同樣會導致 element 的 innerText 發生改變。

所以我們可以說：msg 的 getter 行為觸發了一次副作用，導致 element 的 innterText 發生了變化。

副作用會有多個嗎？

那么明確好了副作用的基本概念之后，那么大家想一想：副作用可能會有多個嗎？

答案是：可以的。

舉個簡單的例子：

<template>
  <div>
    <p>姓名：{{ obj.name }}</p>
    <p>年齡：{{ obj.age }}</p>
  </div>
</template>

<script>
 const obj = ref({
    name: '張三',
    age: 30
  })
  obj.value = {
    name: '李四',
    age: 18
  }
</script>

在這樣的一個代碼中 obj.value 觸發了一次 setter 行為，但是會導致兩個 p 標簽的內容發生改變，也就是產生了兩次副作用。

小節一下

根據本小節我們知道了：

1. 副作用指的是：對數據進行 setter 或 getter 操作時，所產生的一系列后果
2. 副作用可能是會有多個的。

11：Vue 3 框架設計概述

根據前面的學習我們已經知道了：

1. 什么是聲明式
2. 什么是命令式
3. 什么是運行時
4. 什么是編譯時
5. 什么是運行時+編譯時
6. 同時也知道了 框架的設計過程本身是一個不斷取舍的過程

那么了解了這些內容之后，下來 vue3 的一個基本框架設計：

對于 vue3 而言，核心大致可以分為三大模塊：

1. 響應性：reactivity
2. 運行時：runtime
3. 編譯器：compiler

我們以以下基本結構來描述一下三者之間的基本關系：

<template>
	<div>{{ proxyTarget.name }}</div>
</template>

<script>
import { reactive } from 'vue'
export default {
	setup() {
		const target = {
			name: '張三'
		}
		const proxyTarget = reactive(target)
		return {
			proxyTarget
		}
	}
}
</script>

在以上代碼中：

1. 首先，我們通過 reactive 方法，聲明了一個響應式數據。

該方法是 reactivity 模塊對外暴露的一個方法

可以接收一個復雜數據類型，作為  Proxy （現在很多同學可能還不了解什么是 proxy ，沒有關系后面我們會詳細介紹它，現在只需要有個印象即可）的 被代理對象（target）

返回一個 Proxy 類型的 代理對象（proxyTarget）

當 proxyTarget 觸發 setter 或 getter 行為時，會產生對應的副作用

2. 然后，我們在 tempalte 標簽中，寫入了一個 div。我們知道這里所寫入的 html 并不是真實的 html，我們可以把它叫做 模板，該模板的內容會被 編譯器（ compiler ） 進行編譯，從而生成一個 render 函數
3. 最后，vue 會利用 運行時（runtime） 來執行 render 函數，從而渲染出真實 dom

以上就是 reactivity、runtime、compiler 三者之間的運行關系。

當然除了這三者之外， vue 還提供了很多其他的模塊，比如：SSR ，我們這里只是 概述了基本的運行邏輯。