曾經見過為了讓鉤子函數的異步代碼可以同步執行，而對鉤子函數使用async/await，就好像下面的代碼：

// exp-01export default { async created() { const timeKey = 'cost'; console.time(timeKey); console.log('start created'); this.list = await this.getList(); console.log(this.list); console.log('end created'); console.timeEnd(timeKey); }, mounted() { const timeKey = 'cost'; console.time(timeKey); console.log('start mounted'); console.log(this.list.rows); console.log('end mounted'); console.timeEnd(timeKey); }, data() { return {  list: [] }; }, methods: { getList() {  return new Promise((resolve) => {  setTimeout(() => {   return resolve({   rows: [    { name: 'isaac', position: 'coder' }   ]   });  }, 3000);  }); } }};

exp-01 的代碼最后會輸出：

start created
start mounted
undefined
end mounted
mounted cost: 2.88623046875ms
{__ob__: Observer}
end created
created cost: 3171.545166015625ms

很明顯沒有達到預期的效果，為什么？

根據 exp-01 的輸出結果，可以看出代碼的執行順序，首先是鉤子的執行順序：

created => mounted

是的，鉤子的執行順序還是正常的沒有被打亂，證據就是：created鉤子中的同步代碼是在mounted先執行的：

start createdstart mounted

再看看created鉤子內部的異步代碼：

this.list = await this.getList();

可以看見this.list的打印結果

end mountedmounted cost: 2.88623046875ms// 這是created鉤子打印的this.list{__ob__: Observer}end created

在mounted鉤子執行完畢之后才打印，言外之意是使用async/await的鉤子內部的異步代碼并沒有起到阻塞鉤子主線程的執行。這里說的鉤子函數的主線程是指：

beforeCreate => created => beforeMount => mounted => ...

會寫出以上代碼的原因我估計有兩個：

exp-01

正文

剖析一下

前言中針對代碼的執行流程分析了一下，很明顯沒有如期望的順序執行，我們先來回顧一下期望的順序是什么

// step 1created() { // step 1.1 let endTime; const startTime = Date.now(); console.log(`start created: ${startTime}ms`); // step 1.2 this.list = await this.getList(); endTime = Date.now(); console.log(this.list); console.log(`end created: ${endTime}ms, cost: ${endTime - startTime}ms`);},// step 2mounted() { let endTime; const startTime = Date.now(); console.log(`start mounted: ${startTime}ms`); console.log(this.list.rows); endTime = Date.now(); console.log(`end mounted: ${endTime}ms, cost: ${endTime - startTime}ms`);}// step 1 => step 1.1 => step 1.2 => step 2

期望的打印結果是：

// step 1(created)start created// this.list{__ob__: Observer}end createdcreated cost: 3171.545166015625ms// step 2(mounted)start mounted// this.list.rows[{…}, __ob__: Observer]end mountedmounted cost: 2.88623046875ms

對比實際的打印和期望的打印，就知道問題出在created鉤子內使用了await的異步代碼，并沒有達到我們期望的那種的“異步代碼同步執行”的效果，僅僅是一定程度上達到了這個效果。

下面來分析一下為什么會出現這個非預期的結果！

在分析前，讓我們來回顧一下一些javascript的基礎知識！看看下面這段代碼：

(function __main() { console.log('start'); setTimeout(() => { console.log('console in setTimeout'); }, 0); console.log('end');})()// outputstartendconsole in setTimeout

這個打印順序有沒有讓你想到什么？！

任務隊列！

我們都知道JavaScript的代碼可以分成兩類：

同步代碼 和 異步代碼

同步代碼會在主線程按照編寫順序執行；

異步代碼的觸發過程（注意是觸發，比如異步請求的發起，就是在主線程同步觸發的）是同步的，但是異步代碼的實際處理邏輯（回調函數）則會在異步代碼有響應時將處理邏輯代碼推入任務隊列（也叫事件隊列），瀏覽器會在主線程（指當前執行環境的同步代碼）代碼執行完畢后以一定的周期檢測任務隊列，若有需要處理的任務，就會讓隊頭的任務出隊，推入主線程執行。

比如現在我們發起一個異步請求：

// exp-02console.log('start');axios.get('http://xxx.com/getList') .then((resp) => { console.log('handle response'); }) .catch((error) => { console.error(error); });console.log('end');

在主線程中，大概首先會發生如下過程：

// exp-03// step 1console.log('start');// step 2axios.get('http://xxx.com/getList'); // 此時回調函數（即then內部的邏輯）還沒有被調用// step 3console.log('end');

在看看瀏覽器此時在干什么！

此時事件輪詢（Event Loop）登場，其實并非此時才登場，而是一直都在！

“事件輪詢”這個機制會以一定的周期檢測任務隊列有沒有可執行的任務（所謂任務其實就是callback），有即出隊執行。

當 step 2 的請求有響應了，異步請求的回調函數就會被添加到任務隊列（Task Queue）或者 稱為 事件隊列(Event Queue)，然后等到事件輪詢的下一次檢測任務隊列，隊列里面任務就會依次出隊，進入主線程執行：即執行下面的代碼：

// 假定沒有出錯的話((resp) => { console.log('handle response');})()

到此，簡短科普了任務隊列的機制，聯想 exp-01 的代碼，大概知道出現非預期結果的原因了吧！

created鉤子中的await函數，雖然是在一定程度上是同步的，但是他還是被掛起了，實際的處理邏輯（this.list =resp.xxx）則在響應完成后才被添加進任務隊列，并且在主線程的同步代碼執行完畢后執行。 下面是將延時時間設為0后的打印：

start createdstart mountedundefinedend mountedmounted cost: 2.88623046875ms{__ob__: Observer}end createdcreated cost: 9.76611328125ms

這側面說明了await函數確實被被掛起，回調被添加到任務隊列，在主線程代碼執行完畢后等待執行。

然后是為什么說 exp-01 的代碼是一定程度的同步呢？！

同步執行的另一個意思是不是就是：阻塞當前線程的繼續執行直到當前邏輯執行完畢~

看看 exp-01 的打印:

{__ob__: Observer}end createdcreated cost: 3171.545166015625ms

end created 這句打印，是主線程的代碼，如果是一般的異步請求的話，這句打印應該是在 {__ob__: Observer} 這句打印之前的yo，至于為什么會這樣，這里就不多解析，自行google！

另外，這里來個小插曲，你應該注意到，我一直強調，回調函數被添加進任務隊列的時機是在響應完成之后，沒錯確實如此的！

但在不清除這個機制前，你大概會有兩種猜想：

1.在觸發異步代碼的時，處理邏輯就會被添加進任務隊列；
2.上面說到的，在異步代碼響應完成后，處理邏輯才會被添加進任務隊列；

其實大可推斷一下

隊列的數據結構特征是：先進先出（First in First out）

此時假如主線程中有兩個異步請求如下：

// exp-04syncRequest01(callback01);syncRequest02(callback02);

假設處理機制是第一點描述那樣，那么callback01就會先被添加進任務隊列，然后是callback02。

然后，我們再假設syncRequest01的響應時間是10s，syncRequest02的響應時間是5s。

到這里，有沒有察覺到違和感！

異步請求的實際表現是什么？是誰快誰的回調先被執行，對吧！那么實際表現就是callback02會先于callback01執行！

那么基于這個事實，再看看上面的假設（callback01會執行）~

ok！插曲完畢！

解法

首先讓我回顧一下目的，路由組件對異步請求返回的數據有強依賴，因此希望阻塞組件的渲染流程，待到異步請求響應完畢之后再執行。

這就是我們需要做的事情，需要強調的一點是： 我們對數據有強依賴 ，言外之意就是數據沒有按預期返回，就會導致之后的邏輯出現不可避免的異常。

接下來，我們就需要探討一下解決方案！

組件內路由守衛了解一下！？

beforeRouteEnter
beforeRouteUpdate (2.2 新增)
beforeRouteLeave

這里需要用到的路由守衛是： beforeRouterEnter ， 先看代碼：

// exp-05export default { beforeRouteEnter(to, from, next) { this.showLoading(); this.getList()  .then((resp) => {  this.hideLoading();  this.list = resp.data;  next();  })  .catch((error) => {  this.hideLoading();  // handle error  }); }, mounted() { let endTime; const startTime = Date.now(); console.log(`start mounted: ${startTime}ms`); console.log(this.list.rows); endTime = Date.now(); console.log(`end mounted: ${endTime}ms, cost: ${endTime - startTime}ms`); },};

路由守衛 beforeRouterEnter ，觸發這個鉤子后，主線程都會阻塞，頁面會一直保持假死狀態，直到在調用 beforeRouterEnter 的回調函數 next ，才會跳轉路由進行新路由組件的渲染。

看起這個解決方案相當適合上面我們提出的需求，在調用 next 前，就可以去拉取數據！

但是如剛剛說到的，頁面在一直假死，加入數據獲取花費時間過長就難免變得很難看，用戶體驗未免太差

為此，在 exp-05 中我在請完成前后分別調用了 this.showLoading() 和 this.hideLoading() 以便頁面 keep-alive 。

這個處理假死的loading有沒有讓你想到寫什么，沒錯就是下面這個github跳轉頁面是頂部的小藍條

想想就有點cool，當然還有很多的實現方式提升用戶體驗，比如作為body子元素的全屏loading，或者button-loading等等……

當然，我們知道阻塞主線程怎么都是阻塞了，loading只是一種自欺欺人式的優化（此時這個成語可不是什么貶義的詞語）！

因此，不是對數據有非常強的依賴，都應在路由的鉤子進行數據抓取，這樣就可以讓用戶“更快”地跳轉到目的頁。為避免頁面對數據依賴拋出的異常（大概就是 undefined of xxx ），我們可以對初始數據進行一些預設，比如 exp-01 中對 this.list.rows 的依賴，我們可以預設 this.list ：

list: { rows: []}

這樣就不會拋出異常，待到異步請求完成，基于vue的update機制二次渲染我們的預期數據~

小結

對于 exp-01 的寫法，也不能說他是錯誤或不好的寫法，凡事都要看我們是出于什么目的，如果僅僅是為了保證多個異步函數的執行順序， exp-01 的寫法沒有任何錯誤，因此async/await不能用在路由鉤子上什么的并不存在！