javascript的執(zhí)行順序是怎樣的？這個問題其實很緊張，弄清楚是需要花點時間，我很簡單說幫一下忙：1、簡單的方法js本身是一種單線程語言，并不代表它相同時間只做一件事情，代碼也會從上到下順序負責執(zhí)

javascript的執(zhí)行順序是怎樣的？

這個問題其實很緊張，弄清楚是需要花點時間，我很簡單說幫一下忙：

1、簡單的方法js本身是一種單線程語言，并不代表它相同時間只做一件事情，代碼也會從上到下順序負責執(zhí)行

2、js在負責執(zhí)行前的有個預(yù)處理的過程，會把var聲明的變量和函數(shù)聲明實力提升到先執(zhí)行上下文的頂部，所以才在它們被定義之前是可以不取得它們的聲明的，這點是需要注意

3、js在不能執(zhí)行過程中，會碰到同步和異步運行兩種任務(wù)

4、同步任務(wù)會還沒它有先執(zhí)行結(jié)果才會再往后面想執(zhí)行

5、異步運行任務(wù).例如IO請求、事件、定時器等，js的主線程不可能再等待它們的運行結(jié)果，變會不再往后面走（有些異步任務(wù)依賴感瀏覽器的多線程能力比如只是請求等）

6、這些異步任務(wù)會被放入任務(wù)隊列，主線程的回調(diào)函數(shù)會被扯起，等自己主線程執(zhí)行完畢，會去循環(huán)任務(wù)隊列中是否需要有能夠完成的異步任務(wù)，如果有可能會把它拋入主線程并執(zhí)行或者的回調(diào)函數(shù)，直到任務(wù)隊列被數(shù)據(jù)清空

7、任務(wù)隊列又兩類宏任務(wù)和微任務(wù)，宏任務(wù)和script整體代碼、定時器等，微任務(wù)除了

、promise等

8、js引擎簡單的方法從宏任務(wù)中接過第一個任務(wù)，執(zhí)行完畢后，將微任務(wù)中的所有任務(wù)收起，按順序徹底不能執(zhí)行；按這樣的節(jié)奏周而復(fù)始，待到兩個隊列中的任務(wù)都取完。

我說的比較比較簡單點，自己也可以去網(wǎng)上搜索更具體點的答案！

Token是什么？和session、cookie相比，使用場景有什么區(qū)別？

在Web開發(fā)領(lǐng)域，完全相信大家對此Cookie和Session都很認識，Cookie和Session是會話盡量技術(shù)的解決方案。隨著技術(shù)的發(fā)展，Token機制再次出現(xiàn)在我們面前，不過很多開發(fā)者是對Token和Cookie、Session的區(qū)別及使用場景看出不清。

Cookie和Session的用途要知道我們不能訪問網(wǎng)站也是通過HTTP協(xié)議或HTTPS協(xié)議來能完成的，HTTP協(xié)議它本身是小孩游神的協(xié)議（即：服務(wù)器沒能猜得出哪些請求是來源于同個客戶）。而業(yè)務(wù)層面會不屬于到客戶端與服務(wù)器端的交互（同網(wǎng)站下多個頁面間能寬帶共享數(shù)據(jù)），此時服務(wù)器端可以要一直保持會話狀態(tài)，那樣的話才能并且用戶身份的鑒別。

的原因HTTP無狀態(tài)的特性，如果沒有要實話客戶端和服務(wù)器端的會話保持，那你必須其它機制來基于，于是Cookie和Session應(yīng)運而生。

通常情況下，Session和Cookie是可以搭配在一起可以使用的。

Token是什么上面說到的Session和Cookie機制來盡量會話，會存在一個問題：客戶端瀏覽器如果保存自己的SessionID即可解決，而服務(wù)器卻要能保存所有用戶的Session信息，這相對于服務(wù)器來說開銷較大，不過不借用服務(wù)器的擴展（諸如服務(wù)器集群時，Session該如何網(wǎng)絡(luò)同步讀取是個問題）！

只好有人認真思索，如果沒有把Session信息讓客戶端來交給你不過根本無法偽造不就可以不能解決這個問題了？進而有了Token機制。

Token學(xué)名為“令牌”，它的構(gòu)成是：

uid：用戶同樣身份標識

timestamp：當前時間戳

sign：簽名字符串，以免第三方變造數(shù)據(jù)；簽名密鑰是讀取在服務(wù)器端的，其它人沒能知道

其它只附加參數(shù)。

Token機制下的認證流程Token機制不過和Cookie機制極其有幾分相似，主要注意有以上流程：

1、用戶登錄參與身份認證，認證最終后服務(wù)器端生成氣體Token趕往給客戶端；

2、客戶端收不到到Token后存放在客戶端（可能保存在Cookie、LocalStorage、SessionStorage中）；

3、客戶端再度幫忙服務(wù)器端時，將Token作為請求頭后放Headers中；

4、服務(wù)器端能接收請求頭中的Token，將用戶參數(shù)按照事先計劃規(guī)則再并且第二次簽名，一次簽名若相同則以為最終，反之數(shù)據(jù)修真者的存在纂改各位失敗的可能。

（生成簽名示例圖）

（不驗證簽名示例圖）

Token與CookieSession的區(qū)別Cookie反正也指揮的是令牌作用，但它是“有狀態(tài)”的；而Token令牌是無狀態(tài)的，更利于分布式部署。

以上應(yīng)該是我的觀點，對于這個問題大家是怎莫平等的眼光的呢？歡迎在下方評論區(qū)聯(lián)系~我是科技領(lǐng)域創(chuàng)作者，十年互聯(lián)網(wǎng)從業(yè)經(jīng)驗，歡迎關(guān)注我清楚大量科技知識！