首先了解一下URL的組成：

從上面的URL可以看出，一個(gè)完整的URL包括以下幾部分：

1、協(xié)議部分：該URL的協(xié)議部分為“http：”，這代表網(wǎng)頁使用的是HTTP協(xié)議。在Internet中可以使用多種協(xié)議，如HTTP，F(xiàn)TP等等本例中使用的是HTTP協(xié)議。在HTTP后面的“//”為分隔符

2、域名部分：該URL的域名部分為“www.baidu.com”。一個(gè)URL中，也可以使用IP地址作為域名使用

3、端口部分：跟在域名后面的是端口，域名和端口之間使用“:”作為分隔符。端口不是一個(gè)URL必須的部分，如果省略端口部分，將采用默認(rèn)端口80

4、虛擬目錄部分：從域名后的第一個(gè)“/”開始到最后一個(gè)“/”為止，是虛擬目錄部分。虛擬目錄也不是一個(gè)URL必須的部分。本例歲明雹中的虛擬目錄是“/news/”

5、文件名部分：從域名后的最后一個(gè)“/”開始到“？”為止，是文件名部分，乎帆如果沒有“?”,則是從域名后的最后一個(gè)“/”開始到“#”為止，是文件部分，如果沒有“？”和“#”，那么從域名后的最后一個(gè)“/”開始到結(jié)束，都是文件名部分。本例中的文件名是“index.asp”。文件名部分也不是一個(gè)URL必須的部分，如果省略該部分，則使用默認(rèn)的文件名

6、錨部分：從“#”開始到最后，都是錨部分。本例中的錨部分是“name”。錨部分也不是一個(gè)URL必須的部分

7、參數(shù)部分：從“？”開始到“#”為止之間的部分為參數(shù)槐御部分，又稱搜索部分、查詢部分。本例中的參數(shù)部分為“boardID=5&ID=24618&page=1”。參數(shù)可以允許有多個(gè)參數(shù)，參數(shù)與參數(shù)之間用“&”作為分隔符。

很多大公司面試喜歡問這樣一道面試題， 輸入U(xiǎn)RL到看見頁面發(fā)生了什么？ ,今天我們來總結(jié)一下。 簡(jiǎn)單來說，共有以下幾個(gè)過程

下面我們來看看具體的細(xì)節(jié)

輸入 www.google.com 網(wǎng)址后，首先在本地的域名服務(wù)器中查找，沒找到去根域名服務(wù)器查找，沒有再去 com 頂級(jí)域名服務(wù)器查找，，如此的類推下去，直到找到IP地址，然后把它記錄在本地，供下次使用。大致過程就是 . -> .com -> google.com. -> www.google.com. 。 (你可能覺得我多寫 .，并木有，這個(gè).對(duì)應(yīng)的就是根域名服務(wù)器，默認(rèn)情況下所有的網(wǎng)址的最后一位都是.，既然是默認(rèn)情況下，為了方便用戶，通常都會(huì)省略，瀏覽器在請(qǐng)求DNS的時(shí)候會(huì)自動(dòng)加上)

既然已經(jīng)懂得了解析的具體過程，我們可以看到上述一共經(jīng)過了N個(gè)過程，每個(gè)過程有一定的消耗和時(shí)間的等待，因此我們得想辦法解決一下這個(gè)問題！

DNS存在著多級(jí)緩存，從離瀏覽器的距離排序的話，有以下幾種: 瀏覽器緩存，系統(tǒng)緩存，路由器緩存，IPS服務(wù)器緩存，根域名服務(wù)器緩存，頂級(jí)域名服務(wù)器緩存，主域名服務(wù)器緩存。

在你的chrome瀏覽器中輸入:chrome://dns/，你可以看到chrome瀏覽器的DNS緩存。

系統(tǒng)緩存主要存在/etc/hosts(Linux系統(tǒng))中

檢查瀏覽器是否有緩存

通過 Cache-Control 和 Expires 來檢查是否命中強(qiáng)緩存，命中則直接取本地磁盤的html（狀態(tài)碼為200 from disk(or memory) cache，內(nèi)存or磁盤）；

如果沒有命中強(qiáng)緩存，則會(huì)向服務(wù)器發(fā)起請(qǐng)求（先進(jìn)行下一步的TCP連接），服務(wù)器通過 Etag 和 Last-Modify 來與服務(wù)器確認(rèn)返回的響應(yīng)是否被更改（協(xié)商緩存），若無更改則返回狀態(tài)碼（304 Not Modified）,瀏覽器取本地緩存；

若強(qiáng)緩存和協(xié)商緩存都沒有命中則返回請(qǐng)求結(jié)果。

不知道你們有沒有注意這樣一件事，你訪問的時(shí)候，每次響應(yīng)的并非是同一個(gè)服務(wù)器（IP地址不同），一般大公司都有成百上千臺(tái)服務(wù)器來支撐訪問，假設(shè)只有一個(gè)服務(wù)器，那它的性能和存儲(chǔ)量要多大才能支撐這樣大量的訪問呢？DNS可以返回一個(gè)合適的機(jī)器的IP給用戶，例如可以根據(jù)每臺(tái)機(jī)器的負(fù)載量，該機(jī)器離用戶地理位置的距離等等，這種過程就是DNS負(fù)載均衡

TCP 協(xié)議通過三次握手建立連接。

翻譯成大白話就是：

為什么是3次？ ：避免 歷史 連接，確認(rèn)客戶端發(fā)來的請(qǐng)求是這次通信的人。

為什么不是4次？ ：3次夠了第四次浪費(fèi)

建立連接的過程是利用客戶服務(wù)器模式，假設(shè)主機(jī)A為客戶端，主機(jī)B為服務(wù)器端。

采用三次握手是為了防止失效的連接請(qǐng)求報(bào)文段突然又傳送到主機(jī)B，因而產(chǎn)生錯(cuò)誤。失效的連接請(qǐng)求報(bào)文段是指：主機(jī)A發(fā)出的連接請(qǐng)求沒有收到主機(jī)B的確認(rèn)，于是經(jīng)過一段時(shí)間后，主機(jī)A又重新向主機(jī)B發(fā)送連接請(qǐng)求，且建立成功，順序完成數(shù)據(jù)傳輸。考慮這樣一種特殊情況，主機(jī)A第一次發(fā)送的連接請(qǐng)求并沒有丟失，而是因?yàn)榫W(wǎng)絡(luò)節(jié)點(diǎn)導(dǎo)致延遲達(dá)到主機(jī)B，主機(jī)B以為是主機(jī)A又發(fā)起的新連接，于是主機(jī)B同意連接，并向主機(jī)A發(fā)回確認(rèn)，但是此時(shí)主機(jī)A根本不會(huì)理會(huì)，主機(jī)B就一直在等待主機(jī)A發(fā)送數(shù)據(jù)，導(dǎo)致主機(jī)B的資源浪費(fèi)。

采用兩次握手不行，原因就是上面說的失效的連接請(qǐng)求的特殊情況。而在三次握手中， client和server都有一個(gè)發(fā)syn和收ack的過程， 雙方都是發(fā)后能收， 表明通信則準(zhǔn)備工作OK.

為什么不是四次握手呢？ 大家應(yīng)該知道通信中著名的藍(lán)軍紅軍約定， 這個(gè)例子說明， 通信不可能100%可靠， 而上面的三次握手已經(jīng)做好了通信的準(zhǔn)備工作， 再增加握手， 并不能顯著提高可靠性， 而且也沒有必要。

第一次握手 ：

客戶端發(fā)送syn包(Seq=x)到服務(wù)器，并進(jìn)入SYN_SEND狀態(tài)，等待服務(wù)器確認(rèn)；

第二次握手：

服務(wù)器收到syn包，必須確認(rèn)客戶的SYN（ack=x+1），同時(shí)自己也發(fā)送一個(gè)SYN包（Seq=y），即SYN+ACK包，此時(shí)服務(wù)器進(jìn)入SYN_RECV狀態(tài)；

第三次握手：

客戶端收到服務(wù)器的SYN ACK包，向服務(wù)器發(fā)送確認(rèn)包ACK(ack=y+1)，此包發(fā)送完畢，客戶端和服務(wù)器進(jìn)入ESTABLISHED狀態(tài)，完成三次握手。

握手過程中傳送的包里不包含數(shù)據(jù)，三次握手完畢后，客戶端與服務(wù)器才正式開始傳送數(shù)據(jù)。理想狀態(tài)下，TCP連接一旦建立，在通信雙方中的任何一方主動(dòng)關(guān)閉連接之前，TCP 連接都將被一直保持下去。

要先申請(qǐng)CA證書，并安裝在服務(wù)器上（一個(gè)文件，配置nginx支持監(jiān)聽443端口開啟ssl并設(shè)置證書路徑）

瀏覽器發(fā)送請(qǐng)求；

網(wǎng)站從瀏覽器發(fā)過來的加密規(guī)則中選一組自身也支持的加密算法和hash算法，并向?yàn)g覽器發(fā)送帶有公鑰的證書，當(dāng)然證書還包含了很多信息，如網(wǎng)站地址、證書的頒發(fā)機(jī)構(gòu)、過期時(shí)間等。

瀏覽器解析證書。

驗(yàn)證證書的合法性。如頒發(fā)機(jī)構(gòu)是否合法、證書中的網(wǎng)站地址是否與訪問的地址一致，若不合法，則瀏覽器提示證書不受信任，若合法，瀏覽器會(huì)顯示一個(gè)小鎖頭。

若合法，或用戶接受了不合法的證書，瀏覽器會(huì)生成一串隨機(jī)數(shù)的密碼（即密鑰），并用證書中提供的公鑰加密。

使用約定好的hash計(jì)算握手消息，并使用生成的隨機(jī)數(shù)（即密鑰）對(duì)消息進(jìn)行加密，最后將之前生成的所有消息一并發(fā)送給網(wǎng)站服務(wù)器。

網(wǎng)站服務(wù)器解析消息。用已有的私鑰將密鑰解密出來，然后用密鑰解密發(fā)過來的握手消息，并驗(yàn)證是否跟瀏覽器傳過來的一致。然后再用密鑰加密一段握手消息，發(fā)送給瀏覽器。

瀏覽器解密并計(jì)算握手消息的HASH，如果與服務(wù)端發(fā)來的HASH一致，此時(shí)握手過程結(jié)束，之后所有的通信數(shù)據(jù)將由之前瀏覽器生成的隨機(jī)密碼并利用對(duì)稱加密算法進(jìn)行加密。這里瀏覽器與網(wǎng)站互相發(fā)送加密的握手消息并驗(yàn)證，目的是為了保證雙方都獲得了一致的密碼，并且可以正常的加密解密數(shù)據(jù)，為后續(xù)真正數(shù)據(jù)的傳輸做一次測(cè)試。

發(fā)送HTTP請(qǐng)求

首先科補(bǔ)一個(gè)小知識(shí)，HTTP的端口為80/8080，而HTTPS的端口為443

發(fā)送HTTP請(qǐng)求的過程就是構(gòu)建HTTP請(qǐng)求報(bào)文并通過TCP協(xié)議中發(fā)送到服務(wù)器指定端口 請(qǐng)求報(bào)文由 請(qǐng)求行 ， 請(qǐng)求抱頭 ， 請(qǐng)求正文 組成。

請(qǐng)求行

請(qǐng)求行的格式為 Method Request-URL HTTP-Version CRLF eg: GET index.html HTTP/1.1 常用的方法有: GET , POST , PUT , DELETE , OPTIONS , HEAD 。

常見的請(qǐng)求方法區(qū)別

這里主要展示 POST 和 GET 的區(qū)別

常見的區(qū)別

注意一點(diǎn)你也可以在GET里面藏body，POST里面帶參數(shù)

重點(diǎn)區(qū)別

GET 會(huì)產(chǎn)生一個(gè) TCP 數(shù)據(jù)包，而 POST 會(huì)產(chǎn)生兩個(gè) TCP 數(shù)據(jù)包。

詳細(xì)的說就是：

注意一點(diǎn)，并不是所有的瀏覽器都會(huì)發(fā)送兩次數(shù)據(jù)包，F(xiàn)irefox就發(fā)送一次

請(qǐng)求報(bào)頭

請(qǐng)求報(bào)頭允許客戶端向服務(wù)器傳遞請(qǐng)求的附加信息和客戶端自身的信息。

從圖中可以看出，請(qǐng)求報(bào)頭中使用了Accept, Accept-Encoding, Accept-Language, Cache-Control, Connection, Cookie等字段。Accept用于指定客戶端用于接受哪些類型的信息，Accept-Encoding與Accept類似，它用于指定接受的編碼方式。Connection設(shè)置為Keep-alive用于告訴客戶端本次HTTP請(qǐng)求結(jié)束之后并不需要關(guān)閉TCP連接，這樣可以使下次HTTP請(qǐng)求使用相同的TCP通道，節(jié)省TCP連接建立的時(shí)間。

請(qǐng)求正文

當(dāng)使用POST, PUT等方法時(shí)，通常需要客戶端向服務(wù)器傳遞數(shù)據(jù)。這些數(shù)據(jù)就儲(chǔ)存在請(qǐng)求正文中。在請(qǐng)求包頭中有一些與請(qǐng)求正文相關(guān)的信息，例如: 現(xiàn)在的Web應(yīng)用通常采用Rest架構(gòu)，請(qǐng)求的數(shù)據(jù)格式一般為json。這時(shí)就需要設(shè)置 Content-Type: application/json 。

更重要的事情-HTTP緩存

HTTP屬于客戶端緩存，我們常認(rèn)為瀏覽器有一個(gè)緩存數(shù)據(jù)庫，用來保存一些靜態(tài)文件，下面我們分為以下幾個(gè)方面來簡(jiǎn)單介紹HTTP緩存

緩存的規(guī)則

緩存規(guī)則分為 強(qiáng)制緩存 和 協(xié)商緩存

強(qiáng)制緩存

當(dāng)緩存數(shù)據(jù)庫中有客戶端需要的數(shù)據(jù)，客戶端直接將數(shù)據(jù)從其中拿出來使用（如果數(shù)據(jù)未失效），當(dāng)緩存服務(wù)器沒有需要的數(shù)據(jù)時(shí)，客戶端才會(huì)向服務(wù)端請(qǐng)求。

又稱對(duì)比緩存。客戶端會(huì)先從緩存數(shù)據(jù)庫拿到一個(gè)緩存的標(biāo)識(shí)，然后向服務(wù)端驗(yàn)證標(biāo)識(shí)是否失效，如果沒有失效服務(wù)端會(huì)返回304，這樣客戶端可以直接去緩存數(shù)據(jù)庫拿出數(shù)據(jù)，如果失效，服務(wù)端會(huì)返回新的數(shù)據(jù)

強(qiáng)制緩存

對(duì)于強(qiáng)制緩存，服務(wù)器響應(yīng)的header中會(huì)用兩個(gè)字段來表明——Expires和Cache-Control。

Expires

Exprires的值為服務(wù)端返回的數(shù)據(jù)到期時(shí)間。當(dāng)再次請(qǐng)求時(shí)的請(qǐng)求時(shí)間小于返回的此時(shí)間，則直接使用緩存數(shù)據(jù)。但由于服務(wù)端時(shí)間和客戶端時(shí)間可能有誤差，這也將導(dǎo)致緩存命中的誤差，另一方面，Expires是HTTP1.0的產(chǎn)物，故現(xiàn)在大多數(shù)使用Cache-Control替代。

Cache-Control

Cache-Control有很多屬性，不同的屬性代表的意義也不同。

協(xié)商緩存

協(xié)商緩存需要進(jìn)行對(duì)比判斷是否可以使用緩存。瀏覽器第一次請(qǐng)求數(shù)據(jù)時(shí)，服務(wù)器會(huì)將緩存標(biāo)識(shí)與數(shù)據(jù)一起響應(yīng)給客戶端，客戶端將它們備份至緩存中。再次請(qǐng)求時(shí)，客戶端會(huì)將緩存中的標(biāo)識(shí)發(fā)送給服務(wù)器，服務(wù)器根據(jù)此標(biāo)識(shí)判斷。若未失效，返回304狀態(tài)碼，瀏覽器拿到此狀態(tài)碼就可以直接使用緩存數(shù)據(jù)了。

對(duì)于協(xié)商緩存來說，緩存標(biāo)識(shí)我們需要著重理解一下，下面我們將著重介紹它的兩種緩存方案。

Last-Modified

Last-Modified：服務(wù)器在響應(yīng)請(qǐng)求時(shí)，會(huì)告訴瀏覽器資源的最后修改時(shí)間。

從字面上看，就是說：從某個(gè)時(shí)間節(jié)點(diǎn)算起，是否文件被修改了

這兩個(gè)的區(qū)別是一個(gè)是修改了才下載一個(gè)是沒修改才下載。

Last-Modified 說好卻也不是特別好，因?yàn)槿绻诜?wù)器上，一個(gè)資源被修改了，但其實(shí)際內(nèi)容根本沒發(fā)生改變，會(huì)因?yàn)長(zhǎng)ast-Modified時(shí)間匹配不上而返回了整個(gè)實(shí)體給客戶端（即使客戶端緩存里有個(gè)一模一樣的資源）。為了解決這個(gè)問題，HTTP1.1推出了Etag。

Etag

Etag：服務(wù)器響應(yīng)請(qǐng)求時(shí)，通過此字段告訴瀏覽器當(dāng)前資源在服務(wù)器生成的唯一標(biāo)識(shí)（生成規(guī)則由服務(wù)器決定）

但是實(shí)際應(yīng)用中由于Etag的計(jì)算是使用算法來得出的，而算法會(huì)占用服務(wù)端計(jì)算的資源，所有服務(wù)端的資源都是寶貴的，所以就很少使用Etag了。

緩存的優(yōu)點(diǎn)

不同刷新的請(qǐng)求執(zhí)行過程

瀏覽器地址欄中寫入U(xiǎn)RL，回車

F5

Ctrl+F5

服務(wù)器處理請(qǐng)求并返回HTTP報(bào)文

它會(huì)對(duì)TCP連接進(jìn)行處理，對(duì)HTTP協(xié)議進(jìn)行解析，并按照?qǐng)?bào)文格式進(jìn)一步封裝成HTTP Request對(duì)象，供上層使用。這一部分工作一般是由Web服務(wù)器去進(jìn)行，我使用過的Web服務(wù)器有Tomcat, Nginx和Apache等等 HTTP報(bào)文也分成三份， 狀態(tài)碼 ， 響應(yīng)報(bào)頭 和 響應(yīng)報(bào)文

狀態(tài)碼

狀態(tài)碼是由3位數(shù)組成，第一個(gè)數(shù)字定義了響應(yīng)的類別，且有五種可能取值:

平時(shí)遇到比較常見的狀態(tài)碼有:200, 204, 301, 302, 304, 400, 401, 403, 404, 422, 500

常見狀態(tài)碼區(qū)別

200 成功

請(qǐng)求成功，通常服務(wù)器提供了需要的資源。

204 無內(nèi)容

服務(wù)器成功處理了請(qǐng)求，但沒有返回任何內(nèi)容。

301 永久移動(dòng)

請(qǐng)求的網(wǎng)頁已永久移動(dòng)到新位置。 服務(wù)器返回此響應(yīng)（對(duì) GET 或 HEAD 請(qǐng)求的響應(yīng)）時(shí)，會(huì)自動(dòng)將請(qǐng)求者轉(zhuǎn)到新位置。

302 臨時(shí)移動(dòng)

服務(wù)器目前從不同位置的網(wǎng)頁響應(yīng)請(qǐng)求，但請(qǐng)求者應(yīng)繼續(xù)使用原有位置來進(jìn)行以后的請(qǐng)求。

304 未修改

自從上次請(qǐng)求后，請(qǐng)求的網(wǎng)頁未修改過。 服務(wù)器返回此響應(yīng)時(shí)，不會(huì)返回網(wǎng)頁內(nèi)容。

400 錯(cuò)誤請(qǐng)求

服務(wù)器不理解請(qǐng)求的語法。

401 未授權(quán)

請(qǐng)求要求身份驗(yàn)證。 對(duì)于需要登錄的網(wǎng)頁，服務(wù)器可能返回此響應(yīng)。

403 禁止

服務(wù)器拒絕請(qǐng)求。

404 未找到

服務(wù)器找不到請(qǐng)求的網(wǎng)頁。

422 無法處理

請(qǐng)求格式正確，但是由于含有語義錯(cuò)誤，無法響應(yīng)

500 服務(wù)器內(nèi)部錯(cuò)誤

服務(wù)器遇到錯(cuò)誤，無法完成請(qǐng)求。

響應(yīng)報(bào)頭

常見的響應(yīng)報(bào)頭字段有: Server, Connection...。

響應(yīng)報(bào)文

你從服務(wù)器請(qǐng)求的HTML,CSS,JS文件就放在這里面

就是 Webkit 解析渲染頁面的過程。

這個(gè)過程涉及兩個(gè)比較重要的概念 回流 和 重繪 ，DOM結(jié)點(diǎn)都是以盒模型形式存在，需要瀏覽器去計(jì)算位置和寬度等，這個(gè)過程就是回流。等到頁面的寬高，大小，顏色等屬性確定下來后，瀏覽器開始繪制內(nèi)容，這個(gè)過程叫做重繪。瀏覽器剛打開頁面一定要經(jīng)過這兩個(gè)過程的，但是這個(gè)過程非常非常非常消耗性能，所以我們應(yīng)該盡量減少頁面的回流和重繪

這個(gè)過程中可能會(huì)有dom操作、ajax發(fā)起的http網(wǎng)絡(luò)請(qǐng)求等。

web-socket、ajax等，這個(gè)過程通常是為了獲取數(shù)據(jù)

setTimeout、setInterval、Promise等宏任務(wù)、微任務(wù)隊(duì)列

當(dāng)Render Tree中部分或全部元素的尺寸、結(jié)構(gòu)、或某些屬性發(fā)生改變時(shí)，瀏覽器重新渲染部分或全部文檔的過程稱為回流。

會(huì)導(dǎo)致回流的操作：

一些常用且會(huì)導(dǎo)致回流的屬性和方法：

當(dāng)頁面中元素樣式的改變并不影響它在文檔流中的位置時(shí)（例如：color、background-color、visibility等），瀏覽器會(huì)將新樣式賦予給元素并重新繪制它，這個(gè)過程稱為重繪。

JS的解析是由瀏覽器的JS引擎完成的。由于JavaScript是單線程運(yùn)行，也就是說一個(gè)時(shí)間只能干一件事，干這件事情時(shí)其他事情都有排隊(duì)，但是有些人物比較耗時(shí)（例如IO操作），所以將任務(wù)分為 同步任務(wù) 和 異步任務(wù) ，所有的同步任務(wù)放在主線程上執(zhí)行，形成執(zhí)行棧，而異步任務(wù)等待，當(dāng)執(zhí)行棧被清空時(shí)才去看看異步任務(wù)有沒有東西要搞，有再提取到主線程執(zhí)行，這樣往復(fù)循環(huán)（冤冤相報(bào)何時(shí)了，阿彌陀佛），就形成了Event Loop事件循環(huán)，下面來看看大人物

先看一段代碼

結(jié)果我想大家都應(yīng)該知道。主要來介紹JavaScript的解析，至于Promise等下一節(jié)再說

JavaScript是一門單線程語言，盡管H5中提出了 Web-Worker ，能夠模擬實(shí)現(xiàn)多線程，但本質(zhì)上還是單線程，說它是多線程就是扯淡。

既然是單線程，每個(gè)事件的執(zhí)行就要有順序，比如你去銀行取錢，前面的人在進(jìn)行，后面的就得等待，要是前面的人弄個(gè)一兩個(gè)小時(shí)，估計(jì)后面的人都瘋了，因此，瀏覽器的JS引擎處理JavaScript時(shí)分為 同步任務(wù) 和 異步任務(wù)

這張圖我們可以清楚看到

js引擎存在monitoring process進(jìn)程，會(huì)持續(xù)不斷的檢查主線程執(zhí)行棧是否為空，一旦為空，就會(huì)去Event Queue那里檢查是否有等待被調(diào)用的函數(shù)。 估計(jì)看完這些你對(duì)事件循環(huán)有一定的了解，但是事實(shí)上我們看對(duì)的沒這么簡(jiǎn)單，通常我們會(huì)看到Promise，setTimeout，process.nextTick（），這個(gè)時(shí)候你和我就懵逼。

不同任務(wù)會(huì)進(jìn)入不同的任務(wù)隊(duì)列來執(zhí)行。 JS引擎開始工作后，先在宏任務(wù)中開始第一次循環(huán)（ script里面先執(zhí)行，不過我喜歡把它拎出來，直接稱其進(jìn)入執(zhí)行棧 ），當(dāng)主線程執(zhí)行棧全部任務(wù)被清空后去微任務(wù)看看，如果有等待執(zhí)行的任務(wù)，執(zhí)行全部的微任務(wù)（其實(shí)將其回調(diào)函數(shù)推入執(zhí)行棧來執(zhí)行），再去宏任務(wù)找最先進(jìn)入隊(duì)列的任務(wù)執(zhí)行，執(zhí)行這個(gè)任務(wù)后再去主線程執(zhí)行任務(wù)（例如執(zhí)行```console.log(hello world)這種任務(wù)），執(zhí)行棧被清空后再去微任務(wù)，這樣往復(fù)循環(huán)（冤冤相報(bào)何時(shí)了）

下面來看一段代碼

我們看看它的執(zhí)行情況

具體的執(zhí)行過程大致就是這樣。