大家好，我是程式設計師魚皮。
當我們發現前端報錯時（比如數據為空、數據展示錯誤、點選按鈕後沒有任何反映、送出錯誤等），首先要按 F12 開啟瀏覽器的開發者工具，檢視網路請求的狀態碼和響應結果，從而快速判斷問題到底出現在前端還是後端。
正常情況下，後端返回的狀態碼應該是 200 OK（或者其他 2 開頭的狀態碼），表示正常響應。這個時候，再去看響應的數據是否符合預期：
而如果請求的狀態碼是其他 4 開頭或者 5 開頭的，需要再去針對性地分析。當然，針對不同的狀態碼，我們有一些常見的 Bug 解決套路。
這篇文章，會給大家解釋常見的請求錯誤碼，並列舉一些通用的 Bug 解決方案。
大家以後遇到對應的錯誤碼時，直接在該文件中搜尋解決方案即可，掌握排錯技巧，提高排錯效率~
請求錯誤分碼類
首先我們把錯誤分碼為兩大類：
4xx 客戶端錯誤：一般是指發送請求的機器（前端）出現了問題
5xx 伺服端錯誤：一般是指接受處理請求的機器（後端）出現了問題
透過看錯誤碼的開頭是 4 還是 5，就已經能初步判斷錯誤發生在前端還是後端了。
下面分別講解常見的 4xx 和 5xx 錯誤碼。
4xx 客戶端錯誤
400 Bad Request 錯誤請求
錯誤碼含義：客戶端發送了無效的請求，伺服器無法理解或處理。
可能原因：
請求參數的格式、數量、型別或名稱錯誤。
請求缺少必要的參數、或者參數值不合法。
解決方案：
1）檢查請求參數是否符合介面的要求，確保參數的數量、型別和格式正確。
2）校驗請求參數，確保參數值的合法和完整。
其他建議：
1）可以透過前端校驗（比如表單校驗），提前防止一些不符合要求的參數發送給後端。
2）如果前後端都是自己開發的，可以透過檢視伺服器的日誌來快速定位問題。
401 Unauthorized 未授權
錯誤碼含義：請求未經授權，需要進行身份驗證。
可能原因：
使用者未登入
請求缺少有效的身份驗證資訊
請求攜帶的身份驗證資訊非法，比如登入憑證過期失效、許可權不足等。
解決方案：
1）檢查請求是否包含有效的身份驗證資訊，比如是否攜帶了 Cookie 或 token？Cookie 中是否包含使用者憑證或存取令牌？
2）確認使用者登入態是否過期，可以嘗試重新登入後再次驗證。
3）檢查使用者的許可權，確保使用者具有執行該請求所需的許可權。
其他建議：
1）前端的 Cookie 或 Token 需要設定一個有效期和定期續期的機制，盡量和後端的登入態保持一致，避免使用者正常使用時需要多次登入。
2）如果前後端都是自己開發的，可以透過檢視伺服器的日誌來快速定位問題，找到登入態失效或許可權不足的原因。還可以透過 Debug 的方式檢視是否能夠根據前端發來的請求參數獲取到對應的登入使用者資訊。
403 Forbidden 禁止存取
錯誤碼含義：請求被伺服器拒絕。
可能原因：
請求客戶端的 IP 地址被禁止存取。（一般用於封禁攻擊者）
請求的頻率過高、或者伺服器壓力過大，限制了存取頻率。（一般用於保護伺服器）
請求的特定資源或特定操作不允許存取。（一般用於許可權控制）
解決方案：
1）檢查伺服器的存取限制策略（比如防火墻、Nginx 閘道器），確保請求不受到 IP 地址限制或存取頻率限制的影響。
2）檢查請求的資源是否設定了正確的許可權控制，確保請求的使用者有權存取該資源。
其他建議：
1）伺服端合理設定存取控制策略，確保資源的安全性和保密性。
2）伺服端提供清晰的錯誤提示，讓使用者（前端）了解其存取受限的原因。
3）前端註意控制請求的發送頻率，比如不要讓使用者在搜尋框中每輸入一個字就發送一次搜尋請求，可透過防抖、節流等方式進行控制。
404 Not Found 資源不存在
錯誤碼含義：請求的資源不存在，伺服器無法找到對應的資源。
可能原因：
請求的 URL 地址錯誤（比如拼寫錯誤、路徑字首錯誤）
請求的資源 id 或查詢條件錯誤
請求的資源被刪除或移動
解決方案：
1）如果顯示整個網頁或資原始檔不存在，檢查請求的 URL 地址，確保其正確指向需要存取的資源。
2）如果是請求後端無法得到數據（比如查詢為空），確認請求條件是否正確，以及資料庫內是否存在數據。
3）如果使用 Nginx 等閘道器來部署資源，檢查 Nginx 的配置是否正確，比如 Vue 或 React 框架寫出來的 SPA 單頁面套用，需要給 Nginx 配置 try_files。
用什麽框架開發，就要在部署的時候去參考官方文件，比如 Ant Design Pro 官方的部署文件：https://pro.ant.design/zh-CN/docs/deploy 。
其他建議：
1）前端開發時，在使用者搜尋不到資源或者查詢為空時，建議提供友好的錯誤頁面或錯誤提示，引導使用者存取其他相關資源（或回到主頁）。
2）如果前後端都是自己開發的，可以透過檢視伺服器的日誌、打印出的 SQL 語句、檢視資料庫等方式來快速定位問題。
405 Method Not Allowed 方法錯誤
錯誤碼含義：請求方法不被允許，伺服器不支持當前請求使用的 HTTP 方法。
可能原因：客戶端發送請求時指定的方法（GET / POST / PUT 等）和後端介面要求的方法不匹配，比如使用 GET 型別去呼叫只支持 POST 型別的介面。
解決方案：
1）認真閱讀後端介面文件，並檢查前端發送請求的 HTTP 方法是否正確，確保與後端介面支持的方法相匹配。
其他建議：
1）前端開發時，一定要嚴格按照後端介面文件的規範來，比如請求型別、參數、數據格式等。如果感覺後端介面設計不合理，應當及時與後端開發同學交流協商。一般在設計階段，介面是由後端主導、前端和後端同學一起確認的。
5xx 伺服端錯誤
500 Internal Server Error 伺服器內部錯誤
錯誤碼含義：後端伺服器內部發生了意外錯誤，導致無法正確完成請求。這是後端最常出現的一類錯誤。
可能原因：伺服器在處理請求的過程中遇到了意外情況，比如程式碼邏輯錯誤、執行時異常、資源連線異常、資源耗盡、系統操作異常等。
解決方案：
1）檢視伺服器日誌，了解錯誤的詳細資訊，以便定位問題。
2）檢查伺服器端的程式碼，建議透過逐行 Debug 的方式，確保程式碼邏輯正確，異常情況得到了妥善處理。
3）確認伺服器所依賴的外部服務（如資料庫、訊息佇列等）是否正常執行。
4）如果是資源耗盡導致的問題，考慮增加伺服器資源或最佳化程式碼邏輯。
其他建議：
1）給伺服器端增加監控和告警機制，便於及時發現和處理異常情況。
2）針對重要的、邏輯復雜的介面，逐行分析可能出現的異常情況，並針對性地捕獲處理。
3）可以使用全域例外處理器，作為一個兜底方案，捕獲到所有意料之外的異常，確保不要直接將大段報錯和伺服器敏感資訊暴露給前端。
502 Bad Gateway 錯誤閘道器
錯誤碼含義：伺服器作為閘道器或代理時，從上遊伺服器接收到無效的響應。
這句話可能有點專業，什麽是上遊伺服器呢？我舉個例子大家就懂了。
對於下圖這個架構，前端不是直接請求後端伺服器，而是透過 Nginx 閘道器進行轉發，那麽後端伺服器（實際處理請求的伺服器）就是上遊伺服器。
在閘道器請求後端伺服器時，如果後端伺服器報錯了、響應異常，那麽閘道器就得不到正確的響應，就會給前端返回 502 錯誤碼。
可能原因：通常是上遊伺服器無法正常響應請求，比如上遊伺服器故障、網路問題或配置錯誤導致。
解決方案：
1）先不走閘道器，單獨向後端伺服器發送請求，確認能否正常收到請求和響應。如果不走閘道器都不能響應，那麽就是後端伺服器本身的問題，透過檢視後端伺服器的日誌分析處理。
2）檢視閘道器的日誌，是否在呼叫後端伺服器時出現了路徑錯誤，並且要檢查網路連線，確保網路通暢，沒有防火墻或代理伺服器的限制。
3）確認閘道器或代理伺服器的配置是否正確，可能需要調整配置來正確地轉發請求。
其他建議：
1）實作監控和告警機制，定期檢查閘道器或代理伺服器的健康狀態，及時發現問題並采取措施處理。
2）如果是後端伺服器因為並行量導致的故障，考慮使用多台後端伺服器進行負載均衡，提高系統的穩定性和可用性。
503 Service Unavailable 服務不可用
錯誤碼含義：伺服器暫時無法處理請求，通常是由於伺服器過載或臨時維護導致。
可能原因：
伺服器過載、資源不足、臨時故障等原因。（比如學校的搶課系統）
伺服器處於維護狀態，暫時不對外開放。
解決方案：
1）等待一段時間後重試，一般伺服器會在短時間內恢復正常。
2）檢查伺服器負載情況，確保伺服器的資源能夠滿足當前請求並行量。
3）檢查伺服器配置和業務邏輯帶來的效能損耗，透過升級伺服器、效能最佳化等方式，使伺服器能夠處理更多並行請求。
其他建議：
1）在部署方式上，使用 Docker 容器管理平台，自動擴縮容，應對突發流量。
2）在系統設計上，實作負載均衡和故障轉移機制，分散流量和提高系統的可用性。
3）透過壓力測試、故障演練等方式，提前了解系統的並行能力上限，並針對上限設計一些限流、熔斷、擴容的措施。
504 Gateway Timeout 閘道器超時
錯誤碼含義：指閘道器在等待上遊伺服器響應的過程中超時。
跟 502 Bad Gateway 錯誤閘道器有點類似，只不過 502 是由於後端伺服器異常響應導致，而 504 是後端伺服器響應太慢了導致。畢竟閘道器要轉發那麽多請求，不可能一直卡在一個請求上耗著。
可能原因：上遊伺服器響應時間過長，閘道器無法及時獲取到響應。
解決方案：
1）檢查上遊伺服器的效能和負載情況，增加資源或者最佳化處理請求的效率，確保能夠及時響應請求。
2）檢查閘道器和上遊伺服器的環通度，可以在閘道器所在的伺服器上使用 curl 命令直接請求上遊伺服器進行測試。
3）如果上遊伺服器的處理本來就是很慢的，可以調整閘道器的超時設定，延長閘道器等待響應的時間。
比如 Nginx 可以采用如下配置：
http {
...
proxy_connect_timeout 30s;
proxy_read_timeout 30s;
...
}
其他建議：
1）如果上遊伺服器的處理較慢，可以采用異步處理的方式，更快地獲取到響應，盡量避免閘道器超時。
2）如果是網路不穩定導致的偶發超時，可以設計重試機制，當出現超時的時候，嘗試重新發送請求。
比如 Nginx 支持
proxy_next_upstream
配置。
OK，以上就是本次分享，希望大家能夠學會自主分析和解決問題，這才是學好編程的關鍵！
👇🏻 點選下方閱讀原文，獲取魚皮往期編程幹貨。
往期推薦
