整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
下文章來源于小林coding ，作者小林coding
想必不少小伙伴面試過程中，會遇到「當鍵入網址后，到網頁顯示，其間發生了什么」的面試題。
這次，小林我帶大家一起探究下，一個數據包在網絡中的心路歷程。
每個階段都有數據包的「心路歷程」，我們一起看看它說了什么？
接下來以下圖較簡單的網絡拓撲模型作為例子，探究探究其間發生了什么？
簡單的網絡模型
瀏覽器做的第一步工作是解析 URL
首先瀏覽器做的第一步工作就是要對 URL 進行解析，從而生發送給 Web 服務器的請求信息。
讓我們看看一條長長的 URL 里的各個元素的代表什么，見下圖：
URL 解析
所以圖中的長長的 URL 實際上是請求服務器里的文件資源。
要是上圖中的藍色部分 URL 元素都省略了，哪應該是請求哪個文件呢？
當沒有路徑名時，就代表訪問根目錄下事先設置的默認文件，也就是 /index.html 或者 /default.html 這些文件，這樣就不會發生混亂了。
生產 HTTP 請求信息
對 URL 進行解析之后，瀏覽器確定了 Web 服務器和文件名，接下來就是根據這些信息來生成 HTTP 請求消息了。
HTTP 的消息格式
一個孤單 HTTP 數據包表示：“我這么一個小小的數據包，沒親沒友，直接發到浩瀚的網絡，誰會知道我呢？誰能載我一層呢？誰能保護我呢？我的目的地在哪呢？”。充滿各種疑問的它，沒有停滯不前，依然踏上了征途！
通過瀏覽器解析 URL 并生成 HTTP 消息后，需要委托操作系統將消息發送給 Web 服務器。
但在發送之前，還有一項工作需要完成，那就是查詢服務器域名對于的 IP 地址，因為委托操作系統發送消息時，必須提供通信對象的 IP 地址。
比如我們打電話的時候，必須要知道對方的電話號碼，但由于電話號碼難以記憶，所以通常我們會將對方電話號 + 姓名保存在通訊錄里。
所以，有一種服務器就專門保存了 Web 服務器域名與 IP 的對應關系，它就是 DNS 服務器。
域名的層級關系
DNS 中的域名都是用句點來分隔的，比如 www.server.com，這里的句點代表了不同層次之間的界限。
在域名中，越靠右的位置表示其層級越高。
畢竟域名是外國人發明，所以思維和中國人相反，比如說一個城市地點的時候，外國喜歡從小到大的方式順序說起（如 XX 街道 XX 區 XX 市 XX 省），而中國則喜歡從大到小的順序（如 XX 省 XX 市 XX 區 XX 街道）。
根域是在最頂層，它的下一層就是 com 頂級域，再下面是 server.com。
所以域名的層級關系類似一個樹狀結構：
DNS 樹狀結構
根域的 DNS 服務器信息保存在互聯網中所有的 DNS 服務器中。
這樣一來，任何 DNS 服務器就都可以找到并訪問根域 DNS 服務器了。
因此，客戶端只要能夠找到任意一臺 DNS 服務器，就可以通過它找到根域 DNS 服務器，然后再一路順藤摸瓜找到位于下層的某臺目標 DNS 服務器。
域名解析的工作流程
至此，我們完成了 DNS 的解析過程。現在總結一下，整個過程我畫成了一個圖。
域名解析的工作流程
DNS 域名解析的過程蠻有意思的，整個過程就和我們日常生活中找人問路的過程類似，只指路不帶路。
數據包表示：“DNS 老大哥厲害呀，找到了目的地了！我還是很迷茫呀，我要發出去，接下來我需要誰的幫助呢?”
通過 DNS 獲取到 IP 后，就可以把 HTTP 的傳輸工作交給操作系統中的協議棧。
協議棧的內部分為幾個部分，分別承擔不同的工作。上下關系是有一定的規則的，上面的部分會向下面的部分委托工作，下面的部分收到委托的工作并執行。
應用程序（瀏覽器）通過調用 Socket 庫，來委托協議棧工作。協議棧的上半部分有兩塊，分別是負責收發數據的 TCP 和 UDP 協議，它們兩會接受應用層的委托執行收發數據的操作。
協議棧的下面一半是用 IP 協議控制網絡包收發操作，在互聯網上傳數據時，數據劊被切分成一塊塊的網絡包，而將網絡包發送給對方的操作就是由 IP 負責的。
此外 IP 中還包括 ICMP 協議和 ARP 協議。
IP 下面的網卡驅動程序負責控制網卡硬件，而最下面的網卡則負責完成實際的收發操作，也就是對網線中的信號執行發送和接收操作。
數據包看了這份指南表示：“原來我需要那么多大佬的協助啊，那我先去找找 TCP 大佬！”
HTTP 是基于 TCP 協議傳輸的，所以在這我們先了解下 TCP 協議。
TCP 包頭格式
我們先看看 TCP 報文頭部的格式：
TCP 包頭格式
首先，源端口號和目標端口號是不可少的，如果沒有這兩個端口號，數據就不知道應該發給哪個應用。
接下來有包的序號，這個是為了解決包亂序的問題。
還有應該有的是確認號，目的是確認發出去對方是否有收到。如果沒有收到就應該重新發送，直到送達，這個是為了解決不丟包的問題。
接下來還有一些狀態位。例如 SYN 是發起一個連接，ACK 是回復，RST 是重新連接，FIN 是結束連接等。TCP 是面向連接的，因而雙方要維護連接的狀態，這些帶狀態位的包的發送，會引起雙方的狀態變更。
還有一個重要的就是窗口大小。TCP 要做流量控制，通信雙方各聲明一個窗口（緩存大小），標識自己當前能夠的處理能力，別發送的太快，撐死我，也別發的太慢，餓死我。
除了做流量控制以外，TCP還會做擁塞控制，對于真正的通路堵車不堵車，它無能為力，唯一能做的就是控制自己，也即控制發送的速度。不能改變世界，就改變自己嘛。
TCP 傳輸數據之前，要先三次握手建立連接
在 HTTP 傳輸數據之前，首先需要 TCP 建立連接，TCP 連接的建立，通常稱為三次握手。
這個所謂的「連接」，只是雙方計算機里維護一個狀態機，在連接建立的過程中，雙方的狀態變化時序圖就像這樣。
TCP 三次握手
所以三次握手目的是保證雙方都有發送和接收的能力。
如何查看 TCP 的連接狀態？
TCP 的連接狀態查看，在 Linux 可以通過 netstat -napt 命令查看。
TCP 連接狀態查看
TCP 分割數據
如果 HTTP 請求消息比較長，超過了 MSS 的長度，這時 TCP 就需要把 HTTP 的數據拆解一塊塊的數據發送，而不是一次性發送所有數據。
MTU 與 MSS
數據會被以 MSS 的長度為單位進行拆分，拆分出來的每一塊數據都會被放進單獨的網絡包中。也就是在每個被拆分的數據加上 TCP 頭信息，然后交給 IP 模塊來發送數據。
數據包分割
TCP 報文生成
TCP 協議里面會有兩個端口，一個是瀏覽器監聽的端口（通常是隨機生成的），一個是 Web 服務器監聽的端口（HTTP 默認端口號是 80， HTTPS 默認端口號是 443）。
在雙方建立了連接后，TCP 報文中的數據部分就是存放 HTTP 頭部 + 數據，組裝好 TCP 報文之后，就需交給下面的網絡層處理。
至此，網絡包的報文如下圖。
TCP 層報文
此時，遇上了 TCP 的 數據包激動表示：“太好了，碰到了可靠傳輸的 TCP 傳輸，它給我加上 TCP 頭部，我不在孤單了，安全感十足啊！有大佬可以保護我的可靠送達！但我應該往哪走呢？”
TCP 模塊在執行連接、收發、斷開等各階段操作時，都需要委托 IP 模塊將數據封裝成網絡包發送給通信對象。
IP 包頭格式
我們先看看 IP 報文頭部的格式：
IP 包頭格式
在 IP 協議里面需要有源地址 IP 和 目標地址 IP：
因為 HTTP 是經過 TCP 傳輸的，所以在 IP 包頭的協議號，要填寫為 06（十六進制），表示協議為 TCP。
假設客戶端有多個網卡，就會有多個 IP 地址，那 IP 頭部的源地址應該選擇哪個 IP 呢？
當存在多個網卡時，在填寫源地址 IP 時，就需要判斷到底應該填寫哪個地址。這個判斷相當于在多塊網卡中判斷應該使用哪個一塊網卡來發送包。
這個時候就需要根據路由表規則，來判斷哪一個網卡作為源地址 IP。
在 Linux 操作系統，我們可以使用 route -n 命令查看當前系統的路由表。
路由表
舉個例子，根據上面的路由表，我們假設 Web 服務器的目標地址是 192.168.10.200。
路由規則判斷
那么假設 Web 服務器的目標地址是 10.100.20.100，那么依然依照上面的路由表規則判斷，判斷后的結果是和第三條目匹配。
第三條目比較特殊，它目標地址和子網掩碼都是 0.0.0.0，這表示默認網關，如果其他所有條目都無法匹配，就會自動匹配這一行。并且后續就把包發給路由器，Gateway 即是路由器的 IP 地址。
IP 報文生成
至此，網絡包的報文如下圖。
IP 層報文
此時，加上了 IP 頭部的數據包表示 ：“有 IP 大佬給我指路了，感謝 IP 層給我加上了 IP 包頭，讓我有了遠程定位的能力！不會害怕在浩瀚的互聯網迷茫了！可是目的地好遠啊，我下一站應該去哪呢？”
生成了 IP 頭部之后，接下來網絡包還需要在 IP 頭部的前面加上 MAC 頭部。
MAC 包頭格式
MAC 頭部是以太網使用的頭部，它包含了接收方和發送方的 MAC 地址等信息。
MAC 包頭格式
在 MAC 包頭里需要發送方 MAC 地址和接收方目標 MAC 地址，用于兩點之間的傳輸。
一般在 TCP/IP 通信里，MAC 包頭的協議類型只使用：
MAC 發送方和接收方如何確認?
發送方的 MAC 地址獲取就比較簡單了，MAC 地址是在網卡生產時寫入到 ROM 里的，只要將這個值讀取出來寫入到 MAC 頭部就可以了。
接收方的 MAC 地址就有點復雜了，只要告訴以太網對方的 MAC 的地址，以太網就會幫我們把包發送過去，那么很顯然這里應該填寫對方的 MAC 地址。
所以先得搞清楚應該把包發給誰，這個只要查一下路由表就知道了。在路由表中找到相匹配的條目，然后把包發給 Gateway 列中的 IP 地址就可以了。
既然知道要發給誰，按如何獲取對方的 MAC 地址呢？
不知道對方 MAC 地址？不知道就喊唄。
此時就需要 ARP 協議幫我們找到路由器的 MAC 地址。
ARP 廣播
ARP 協議會在以太網中以廣播的形式，對以太網所有的設備喊出：“這個 IP 地址是誰的？請把你的 MAC 地址告訴我”。
然后就會有人回答：“這個 IP 地址是我的，我的 MAC 地址是 XXXX”。
如果對方和自己處于同一個子網中，那么通過上面的操作就可以得到對方的 MAC 地址。然后，我們將這個 MAC 地址寫入 MAC 頭部，MAC 頭部就完成了。
好像每次都要廣播獲取，這不是很麻煩嗎？
放心，在后續操作系統會把本次查詢結果放到一塊叫做 ARP 緩存的內存空間留著以后用，不過緩存的時間就幾分鐘。
也就是說，在發包時：
查看 ARP 緩存內容
在 Linux 系統中，我們可以使用 arp -a 命令來查看 ARP 緩存的內容。
ARP 緩存內容
MAC 報文生成
至此，網絡包的報文如下圖。
MAC 層報文
此時，加上了 MAC 頭部的數據包萬分感謝，說道 ：“感謝 MAC 大佬，我知道我下一步要去了哪了！我現在有很多頭部兄弟，相信我可以到達最終的目的地！”。帶著眾多頭部兄弟的數據包，終于準備要出門了。
IP 生成的網絡包只是存放在內存中的一串二進制數字信息，沒有辦法直接發送給對方。因此，我們需要將數字信息轉換為電信號，才能在網線上傳輸，也就是說，這才是真正的數據發送過程。
負責執行這一操作的是網卡，要控制網卡還需要靠網卡驅動程序。
網卡驅動從 IP 模塊獲取到包之后，會將其復制到網卡內的緩存區中，接著會其開頭加上報頭和起始幀分界符，在末尾加上用于檢測錯誤的幀校驗序列。
物理層數據包
最后網卡會將包轉為電信號，通過網線發送出去。
唉，真是不容易，發一個包，真是歷經歷經千辛萬苦。致此，一個帶有許多頭部的數據終于踏上尋找目的地的征途了！
下面來看一下包是如何通過交換機的。交換機的設計是將網絡包原樣轉發到目的地。交換機工作在 MAC 層，也稱為二層網絡設備。
交換機的包接收操作
首先，電信號到達網線接口，交換機里的模塊進行接收，接下來交換機里的模塊將電信號轉換為數字信號。
然后通過包末尾的 FCS 校驗錯誤，如果沒問題則放到緩沖區。這部分操作基本和計算機的網卡相同，但交換機的工作方式和網卡不同。
計算機的網卡本身具有 MAC 地址，并通過核對收到的包的接收方 MAC 地址判斷是不是發給自己的，如果不是發給自己的則丟棄；相對地，交換機的端口不核對接收方 MAC 地址，而是直接接收所有的包并存放到緩沖區中。因此，和網卡不同，交換機的端口不具有 MAC 地址。
將包存入緩沖區后，接下來需要查詢一下這個包的接收方 MAC 地址是否已經在 MAC 地址表中有記錄了。
交換機的 MAC 地址表主要包含兩個信息：
交換機的 MAC 地址表
舉個例子，如果收到的包的接收方 MAC 地址為 00-02-B3-1C-9C-F9，則與圖中表中的第 3 行匹配，根據端口列的信息，可知這個地址位于 3 號端口上，然后就可以通過交換電路將包發送到相應的端口了。
所以，交換機根據 MAC 地址表查找 MAC 地址，然后將信號發送到相應的端口。
當 MAC 地址表找不到指定的 MAC 地址會怎么樣？
地址表中找不到指定的 MAC 地址。這可能是因為具有該地址的設備還沒有向交換機發送過包，或者這個設備一段時間沒有工作導致地址被從地址表中刪除了。
這種情況下，交換機無法判斷應該把包轉發到哪個端口，只能將包轉發到除了源端口之外的所有端口上，無論該設備連接在哪個端口上都能收到這個包。
這樣做不會產生什么問題，因為以太網的設計本來就是將包發送到整個網絡的，然后只有相應的接收者才接收包，而其他設備則會忽略這個包。
有人會說：“這樣做會發送多余的包，會不會造成網絡擁塞呢？”
其實完全不用過于擔心，因為發送了包之后目標設備會作出響應，只要返回了響應包，交換機就可以將它的地址寫入 MAC 地址表，下次也就不需要把包發到所有端口了。
局域網中每秒可以傳輸上千個包，多出一兩個包并無大礙。
此外，如果接收方 MAC 地址是一個廣播地址，那么交換機會將包發送到除源端口之外的所有端口。
以下兩個屬于廣播地址：
數據包通過交換機轉發抵達了路由器，準備要離開土生土長的子網了。此時，數據包和交換機離別時說道：“感謝交換機兄弟，幫我轉發到出境的大門，我要出遠門啦！”
路由器與交換機的區別
網絡包經過交換機之后，現在到達了路由器，并在此被轉發到下一個路由器或目標設備。
這一步轉發的工作原理和交換機類似，也是通過查表判斷包轉發的目標。
不過在具體的操作過程上，路由器和交換機是有區別的。
路由器基本原理
路由器的端口具有 MAC 地址，因此它就能夠成為以太網的發送方和接收方；同時還具有 IP 地址，從這個意義上來說，它和計算機的網卡是一樣的。
當轉發包時，首先路由器端口會接收發給自己的以太網包，然后路由表查詢轉發目標，再由相應的端口作為發送方將以太網包發送出去。
路由器的包接收操作
首先，電信號到達網線接口部分，路由器中的模塊會將電信號轉成數字信號，然后通過包末尾的 FCS 進行錯誤校驗。
如果沒問題則檢查 MAC 頭部中的接收方 MAC 地址，看看是不是發給自己的包，如果是就放到接收緩沖區中，否則就丟棄這個包。
總的來說，路由器的端口都具有 MAC 地址，只接收與自身地址匹配的包，遇到不匹配的包則直接丟棄。
查詢路由表確定輸出端口
完成包接收操作之后，路由器就會去掉包開頭的 MAC 頭部。
MAC 頭部的作用就是將包送達路由器，其中的接收方 MAC 地址就是路由器端口的 MAC 地址。因此，當包到達路由器之后，MAC 頭部的任務就完成了，于是 MAC 頭部就會被丟棄。
接下來，路由器會根據 MAC 頭部后方的 IP 頭部中的內容進行包的轉發操作。
轉發操作分為幾個階段，首先是查詢路由表判斷轉發目標。
路由器轉發
具體的工作流程根據上圖，舉個例子。
假設地址為 10.10.1.101 的計算機要向地址為 192.168.1.100 的服務器發送一個包，這個包先到達圖中的路由器。
判斷轉發目標的第一步，就是根據包的接收方 IP 地址查詢路由表中的目標地址欄，以找到相匹配的記錄。
路由匹配和前面講的一樣，每個條目的子網掩碼和 192.168.1.100 IP 做 & 與運算后，得到的結果與對應條目的目標地址進行匹配，如果匹配就會作為候選轉發目標，如果不匹配就繼續與下個條目進行路由匹配。
如第二條目的子網掩碼 255.255.255.0 與 192.168.1.100 IP 做 & 與運算后，得到結果是 192.168.1.0 ，這與第二條目的目標地址 192.168.1.0 匹配，該第二條目記錄就會被作為轉發目標。
實在找不到匹配路由時，就會選擇默認路由，路由表中子網掩碼為 0.0.0.0 的記錄表示「默認路由」。
路由器的發送操作
接下來就會進入包的發送操作。
首先，我們需要根據路由表的網關列判斷對方的地址。
知道對方的 IP 地址之后，接下來需要通過 ARP 協議根據 IP 地址查詢 MAC 地址，并將查詢的結果作為接收方 MAC 地址。
路由器也有 ARP 緩存，因此首先會在 ARP 緩存中查詢，如果找不到則發送 ARP 查詢請求。
接下來是發送方 MAC 地址字段，這里填寫輸出端口的 MAC 地址。還有一個以太類型字段，填寫 0080 （十六進制）表示 IP 協議。
網絡包完成后，接下來會將其轉換成電信號并通過端口發送出去。這一步的工作過程和計算機也是相同的。
發送出去的網絡包會通過交換機到達下一個路由器。由于接收方 MAC 地址就是下一個路由器的地址，所以交換機會根據這一地址將包傳輸到下一個路由器。
接下來，下一個路由器會將包轉發給再下一個路由器，經過層層轉發之后，網絡包就到達了最終的目的地。
不知你發現了沒有，在網絡包傳輸的過程中，源 IP 和目標 IP 始終是不會變的，一直變化的是 MAC 地址，因為需要 MAC 地址在以太網內進行兩個設備之間的包傳輸。
數據包通過多個路由器道友的幫助，在網絡世界途徑了很多路程，最終抵達了目的地的城門！城門值守的路由器，發現了這個小兄弟數據包原來是找城內的人，于是它就將數據包送進了城內，再經由城內的交換機幫助下，最終轉發到了目的地了。數據包感慨萬千的說道：“多謝這一路上，各路大俠的相助！”
數據包抵達了服務器，服務器肯定高興呀，正所謂有朋自遠方來，不亦樂乎？
服務器高興的不得了，于是開始扒數據包的皮！就好像你收到快遞，能不興奮嗎？
扒皮模型
數據包抵達服務器后，服務器會先扒開數據包的 MAC 頭部，查看是否和服務器自己的 MAC 地址符合，符合就將包收起來。
接著繼續扒開數據包的 IP 頭，發現 IP 地址符合，根據 IP 頭中協議項，知道自己上層是 TCP 協議。
于是，扒開 TCP 的頭，里面有序列號，需要看一看這個序列包是不是我想要的，如果是就放入緩存中然后返回一個 ACK，如果不是就丟棄。TCP頭部里面還有端口號， HTTP 的服務器正在監聽這個端口號。
于是，服務器自然就知道是 HTTP 進程想要這個包，于是就將包發給 HTTP 進程。
服務器的 HTTP 進程看到，原來這個請求是要訪問一個頁面，于是就把這個網頁封裝在
HTTP 響應報文里。
HTTP 響應報文也需要穿上 TCP、IP、MAC 頭部，不過這次是源地址是服務器 IP 地址，目的地址是客戶端 IP 地址。
穿好頭部衣服后，從網卡出去，交由交換機轉發到出城的路由器，路由器就把響應數據包發到了下一個路由器，就這樣跳啊跳。
最后跳到了客戶端的城門把手的路由器，路由器扒開 IP 頭部發現是要找城內的人，于是把包發給了城內的交換機，再由交換機轉發到客戶端。
客戶端收到了服務器的響應數據包后，同樣也非常的高興，客戶能拆快遞了！
于是，客戶端開始扒皮，把收到的數據包的皮扒剩 HTTP 響應報文后，交給瀏覽器去渲染頁面，一份特別的數據包快遞，就這樣顯示出來了！
最后，客戶端要離開了，向服務器發起了 TCP 四次揮手，至此雙方的連接就斷開了。
下面內容的 「我」，代表「臭美的數據包角色」。
（括號的內容）代表我的吐槽，三連呸！
一開始我雖然孤單、不知所措，但沒有停滯不前。我依然滿懷信心和勇氣開始了征途。（你當然有勇氣，你是應用層數據，后面有底層兄弟當靠山，我呸！）
我很慶幸遇到了各路神通廣大的大佬，有可靠傳輸的 TCP、有遠程定位功能的 IP、有指明下一站位置的 MAC 等（你當然會遇到，因為都被計算機安排好的，我呸！）。
這些大佬都給我前面加上了頭部，使得我能在交換機和路由器的轉發下，抵達到了目的地！（哎，你也不容易，不吐槽了，放過你！）
這一路上的經歷，讓我認識到了網絡世界中各路大俠協作的重要性，是他們維護了網絡世界的秩序，感謝他們！（我呸，你應該感謝眾多計算機科學家！）
喜歡請多多關注易杰智科技！
了解常見的JavaScript錯誤可以幫助你更好地調試和故障排除代碼。當你遇到錯誤時，能夠快速識別錯誤類型并找到解決方法，可以節省大量的時間和精力。
通過了解常見的JavaScript錯誤，你可以編寫更健壯和穩定的代碼。你可以預先考慮到可能出現的錯誤情況，并采取適當的措施來處理或避免這些錯誤，從而提高代碼的質量和穩定性。
JavaScript錯誤可能會導致應用程序崩潰、功能失效或不可預料的行為。通過了解常見的JavaScript錯誤并處理它們，可以提供更好的用戶體驗，避免應用程序因錯誤而中斷或表現不正常。
某些JavaScript錯誤可能會暴露應用程序的漏洞，使其易受攻擊。了解這些錯誤并采取適當的安全措施可以幫助你保護應用程序免受潛在的安全威脅。
通過了解常見的JavaScript錯誤，你可以不斷學習和成長。你可以深入了解錯誤的原因、背后的概念和解決方法，從而提高自己的技能和知識水平。
JS報錯會導致程序的執行中斷，代碼無法繼續執行下去。
報錯可能導致程序的功能異常或不可用。例如，如果某個關鍵函數報錯，可能會導致相關功能無法正常運行。
嚴重的JS報錯可能導致整個頁面崩潰，無法正常顯示或交互。
報錯信息可能會被顯示在頁面上，這可能會泄露敏感信息，給攻擊者提供潛在的安全漏洞。
JS報錯可能會導致頁面加載緩慢或卡頓，影響用戶的體驗。
某些報錯可能會導致數據丟失或損壞，特別是在涉及到數據處理或存儲的情況下。
不同瀏覽器對JS的處理方式可能不同，報錯可能會導致兼容性問題，使得頁面在某些瀏覽器上無法正常工作。
因此，及時處理和修復JS報錯是非常重要的，以確保程序的正常運行和用戶體驗。
var num=666;
num();
// Uncaught TypeError: num is not a function
解決方法：確保你對值的操作和使用是符合其類型的。
console.log(foo);
// Uncaught ReferenceError: foo is not defined
解決方法：確保你在使用變量或函數之前進行了正確的聲明和定義。
if (x > 5 { // 缺少右括號
console.log('x is greater than 5');
}
// Uncaught SyntaxError: Unexpected token '{'
解決方法：仔細檢查代碼，確保語法正確，例如括號匹配、分號使用等。
function recursiveFunction() {
recursiveFunction();
}
recursiveFunction();
// Uncaught RangeError: Maximum call stack size exceeded
解決方法：確保你在訪問數組、字符串或其他可迭代對象時，使用的索引或位置在有效范圍內。
function recursiveFunction(depth) {
if (depth===0) {
return;
}
recursiveFunction(depth - 1);
}
recursiveFunction(100);
// 在這個示例中，我們通過增加一個停止條件來修復范圍錯誤。遞歸的深度被限制在100次。
在JavaScript中，EvalError是一個錯誤類型，表示與eval()函數相關的錯誤。然而，在現代的JavaScript環境中，EvalError的使用相對較少。 示例：
eval('alert("Hello, World!");');
// 我們使用eval()函數來執行一個字符串作為JavaScript代碼。如果字符串中的代碼存在語法錯誤或其他問題，就會拋出EvalError。
解決方法：避免使用 eval 函數，盡量使用其他更安全的替代方法。例如使用Function構造函數或解析器工具等。
decodeURIComponent('%');
// Uncaught URIError: URI malformed
解決方法：確保你在使用 URI 相關函數或方法時，提供的參數是合法的。
function createHugeArray() {
var arr=new Array(2000000000);
return arr;
}
createHugeArray()
解決方法：InternalError通常是由于JavaScript引擎或運行時環境中的內部問題導致的，例如堆棧溢出、內存不足等。避免出現無限遞歸、死循環等問題，確保你的代碼邏輯正確。
async function fetchData() {
throw new Error('Something went wrong'); // 拋出一個錯誤
}
fetchData()
.catch(error=> {
console.log('Async error:', error); // 捕獲異步錯誤并進行處理
});
解決方法：使用適當的錯誤處理機制，例如使用 try-catch 或 catch 方法來捕獲和處理異步錯誤。
async function fetchData() {
try {
throw new Error('Something went wrong'); // 拋出一個錯誤
} catch (error) {
console.log('Sync error:', error); // 捕獲同步錯誤并進行處理 }}
fetchData()
.catch(error=> {
console.log('Async error:', error); // 捕獲異步錯誤并進行處理
});
1. 錯誤處理和異常處理是前端開發中不可或缺的一部分，能夠提升用戶體驗，減少用戶流失率：
綜合上述幾種異常錯誤，在部門小程序項目中進行了JS報錯異常優化，第一版本優化后錯誤數上線后由每日最高1374次降低到184次，減少了近86%的錯誤次數，由錯誤人數 694降低到109人，減少了近84%錯誤人數。
2.了解常見錯誤類型和異常類型，以及相應的解決方法，可以幫助我們更好地定位和解決問題。
3. 示例提供了一些常見錯誤的解決方法，但實際情況可能因代碼和環境而異，需要仔細分析和調試代碼。
4. 參考文章提供了更多學習資源和深入了解錯誤處理的內容。
?MDN Web 文檔：https://developer.mozilla.org/
?JavaScript 教程 - W3Schools：https://www.w3schools.com/js/
?JavaScript 錯誤處理和調試 - JavaScript.info：https://javascript.info/try-catch
?JavaScript 異常處理的藝術 - Smashing Magazine：https://www.smashingmagazine.com/2020/08/error-handling-art-javascript/
?JavaScript 異常處理的 8 個技巧 - SitePoint：https://blog.logrocket.com/5-common-javascript-exception-handling-mistakes/
作者：京東零售 孫鵬紅
來源：京東云開發者社區 轉載請注明來源
、新建項目
1、新建===web項目===輸入項目名稱====完成
二、新建html文件
在新建項目中新建html模板
輸入文件名稱：
三、認識基本格式
聯想出基本格式：
四、編輯html文件
運行html，選擇瀏覽器
五、html常用的快捷鍵
（1）ctrl+n+w web項目創建
（2）ctrl+n+h html文檔創建
（3）ctrl+s 保存html頁面（頁面上如果未保存會顯示*號）
（4）ctrl+r html運行
（5）ctrl+z 撤回
（6）！+tab鍵 聯想基本格式
（7）ctrl+/ 注釋和取消注釋
（8）ctrl+鼠標滾輪， 字體方大和縮小
六、認識標簽
（1）H標簽（標題標簽）
（2）p標簽 （段落標簽）
（3）img 標簽（圖片標簽）
兩種：第一種widows上傳圖片，第二種：網上圖片鏈接
第一種
img中顯示圖片
img中引入圖片
第二種：網上圖片的鏈接：
（4） 標簽（空格）
（5）em 標簽表示斜體
（6）i 標簽表示斜體
（7）br 表示換行
（8）b 標簽表示加粗
（9） strong 標簽表示加粗
（10）s 標簽（刪除線）
（11）u 標簽 （下劃線）
（12）font 顏色
（13）sub下標
（14）sup上標
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
