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

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

這個(gè)問題其實(shí)很緊張，弄清楚是需要花點(diǎn)時(shí)間，我很簡單說幫一下忙：

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

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

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

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

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

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

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

、promise等

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

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

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

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

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

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

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

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

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

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

uid：用戶同樣身份標(biāo)識(shí)

timestamp：當(dāng)前時(shí)間戳

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

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

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

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

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

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

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

（生成簽名示例圖）

（不驗(yàn)證簽名示例圖）

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

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