在事件循環(huán)期間的某個(gè)時(shí)刻，運(yùn)行時(shí)會從最先進(jìn)入隊(duì)列的消息開始處理隊(duì)列中的消息。被處理的消息會被移出隊(duì)列，并作為輸入?yún)?shù)來調(diào)用與之關(guān)聯(lián)的函數(shù)。正如前面所提到的，調(diào)用一個(gè)函數(shù)總是會為其創(chuàng)造一個(gè)新的棧幀。函數(shù)的處理會一直進(jìn)行到執(zhí)行棧再次為空為止；然后事件循環(huán)將會處理隊(duì)列中的下一個(gè)消息（如果還有的話）。

目前成都創(chuàng)新互聯(lián)公司已為1000多家的企業(yè)提供了網(wǎng)站建設(shè)、域名、網(wǎng)站空間、網(wǎng)站改版維護(hù)、企業(yè)網(wǎng)站設(shè)計(jì)、義縣網(wǎng)站維護(hù)等服務(wù)，公司將堅(jiān)持客戶導(dǎo)向、應(yīng)用為本的策略，正道將秉承"和諧、參與、激情"的文化，與客戶和合作伙伴齊心協(xié)力一起成長，共同發(fā)展。

"執(zhí)行至完成"

每一個(gè)消息完整地執(zhí)行后，其它消息才會被執(zhí)行。這為程序的分析提供了一些優(yōu)秀的特性，包括：當(dāng)一個(gè)函數(shù)執(zhí)行時(shí)，它不會被搶占，只有在它運(yùn)行完畢之后才會去運(yùn)行任何其他的代碼，才能修改這個(gè)函數(shù)操作的數(shù)據(jù)。這個(gè)模型的一個(gè)缺點(diǎn)在于當(dāng)一個(gè)消息需要太長時(shí)間才能處理完畢時(shí)，Web 應(yīng)用程序就無法處理與用戶的交互，例如點(diǎn)擊或滾動。為了緩解這個(gè)問題，瀏覽器一般會彈出一個(gè)“這個(gè)腳本運(yùn)行時(shí)間過長”的對話框。一個(gè)良好的習(xí)慣是縮短單個(gè)消息處理時(shí)間，并在可能的情況下將一個(gè)消息裁剪成多個(gè)消息。

函數(shù)setTimeout接受兩個(gè)參數(shù)：待加入隊(duì)列的消息和一個(gè)時(shí)間值（可選，默認(rèn)為 0）。這個(gè)時(shí)間值代表了消息被實(shí)際加入到隊(duì)列的最小延遲時(shí)間。如果隊(duì)列中沒有其它消息并且棧為空，在這段延遲時(shí)間過去之后，消息會被馬上處理。但是，如果有其它消息，setTimeout消息必須等待其它消息處理完。因此第二個(gè)參數(shù)僅僅表示最少延遲時(shí)間，而非確切的等待時(shí)間。

零延遲

零延遲并不意味著回調(diào)會立即執(zhí)行。以 0 為第二參數(shù)調(diào)用setTimeout并不表示在 0 毫秒后就立即調(diào)用回調(diào)函數(shù)。

其等待的時(shí)間取決于隊(duì)列里待處理的消息數(shù)量。在下面的例子中，"這是一條消息"將會在回調(diào)獲得處理之前輸出到控制臺，這是因?yàn)檠舆t參數(shù)是運(yùn)行時(shí)處理請求所需的最小等待時(shí)間，但并不保證是準(zhǔn)確的等待時(shí)間。

setTimeout需要等待當(dāng)前隊(duì)列中所有的消息都處理完畢之后才能執(zhí)行，即使已經(jīng)超出了由第二參數(shù)所指定的時(shí)間。

JS執(zhí)行順序

1. JS是從上到下一行一行執(zhí)行。
2. 如果某一行執(zhí)行報(bào)錯(cuò)，則停止執(zhí)行下面的代碼。
3. 先執(zhí)行同步代碼，再執(zhí)行異步代碼

事件循環(huán)的執(zhí)行過程

• 同步代碼，調(diào)用棧執(zhí)行后直接出棧
• 異步代碼，放到Web API中，等待時(shí)機(jī)，等合適的時(shí)候放入回調(diào)隊(duì)列（callbackQueue），等到調(diào)用?？諘r(shí)eventLoop開始工作，輪詢
• 微任務(wù)執(zhí)行時(shí)機(jī)比宏任務(wù)要早
• 微任務(wù)在DOM渲染前觸發(fā)，宏任務(wù)在DOM渲染后觸發(fā)