1. 項(xiàng)目概述為什么我們需要讀懂HTTP的“表情包”做后端開(kāi)發(fā)或者運(yùn)維的朋友每天和服務(wù)器打交道最怕的就是半夜被報(bào)警電話(huà)叫醒一看日志滿(mǎn)屏的4xx、5xx錯(cuò)誤。對(duì)于前端同學(xué)來(lái)說(shuō)最頭疼的莫過(guò)于用戶(hù)反饋“頁(yè)面打不開(kāi)了”而你只能對(duì)著瀏覽器控制臺(tái)里那個(gè)紅色的錯(cuò)誤碼干瞪眼。這個(gè)“HTTP報(bào)錯(cuò)狀態(tài)碼”就像是服務(wù)器和客戶(hù)端之間對(duì)話(huà)的“表情包”和“暗號(hào)”。服務(wù)器不會(huì)說(shuō)話(huà)但它會(huì)用這些三位數(shù)的代碼精準(zhǔn)地告訴你“你找錯(cuò)門(mén)了”404、“你沒(méi)帶鑰匙”401、“我忙不過(guò)來(lái)了”503或者“我徹底宕機(jī)了”500。很多人對(duì)這些狀態(tài)碼的態(tài)度是“用到再查”但我的經(jīng)驗(yàn)是系統(tǒng)地理解它們是構(gòu)建穩(wěn)定、可維護(hù)Web系統(tǒng)的基石。這不僅僅是背幾個(gè)數(shù)字那么簡(jiǎn)單。一個(gè)精準(zhǔn)的404錯(cuò)誤頁(yè)面能提升用戶(hù)體驗(yàn)一個(gè)清晰的403錯(cuò)誤提示能加強(qiáng)安全邊界而對(duì)5xx錯(cuò)誤的快速定位和修復(fù)直接關(guān)系到系統(tǒng)的可用性和SLA服務(wù)等級(jí)協(xié)議。今天我就結(jié)合十多年踩坑填坑的經(jīng)驗(yàn)把這些狀態(tài)碼掰開(kāi)揉碎了講清楚不僅告訴你它們是什么更重點(diǎn)分享在實(shí)際開(kāi)發(fā)、調(diào)試、運(yùn)維中如何利用和應(yīng)對(duì)這些狀態(tài)碼把故障消滅在萌芽狀態(tài)。2. HTTP狀態(tài)碼分類(lèi)體系與設(shè)計(jì)哲學(xué)HTTP狀態(tài)碼由一個(gè)三位整數(shù)和一段簡(jiǎn)短的文本原因短語(yǔ)組成比如404 Not Found。這個(gè)三位數(shù)被精心設(shè)計(jì)為具有分類(lèi)意義首位數(shù)字定義了響應(yīng)的類(lèi)別。2.1 五大類(lèi)別解析從成功到崩潰的頻譜1xx信息響應(yīng)這類(lèi)狀態(tài)碼屬于“臨時(shí)響應(yīng)”意味著請(qǐng)求已被接收需要請(qǐng)求者繼續(xù)執(zhí)行操作。在實(shí)際的HTTP/1.1通信中客戶(hù)端通常不會(huì)直接看到它們因?yàn)樗鼈兌嘣诖砘蚍?wù)器內(nèi)部處理。最常見(jiàn)的例子是100 Continue客戶(hù)端在發(fā)送較大請(qǐng)求體如文件上傳前會(huì)先發(fā)送一個(gè)攜帶Expect: 100-continue頭部的請(qǐng)求“探路”服務(wù)器如果同意接收就會(huì)返回100客戶(hù)端再發(fā)送實(shí)體內(nèi)容。這避免了在服務(wù)器拒絕時(shí)浪費(fèi)帶寬傳輸大量數(shù)據(jù)。2xx成功響應(yīng)這是我們都希望看到的類(lèi)別表示請(qǐng)求被成功處理。但“成功”也有不同的姿勢(shì)200 OK通用成功狀態(tài)。對(duì)于GET請(qǐng)求資源在響應(yīng)體中返回對(duì)于POST通常是操作成功的確認(rèn)。201 Created成功并創(chuàng)建了新資源。最佳實(shí)踐是在響應(yīng)中通過(guò)Location頭部返回新創(chuàng)建資源的URI例如在RESTful API中創(chuàng)建一篇新文章后返回。204 No Content服務(wù)器成功處理了請(qǐng)求但不需要返回任何實(shí)體內(nèi)容。常用于DELETE請(qǐng)求成功后的響應(yīng)或更新操作如PUT后客戶(hù)端視圖無(wú)需刷新的情況。206 Partial Content這是實(shí)現(xiàn)斷點(diǎn)續(xù)傳或流媒體播放的關(guān)鍵。當(dāng)客戶(hù)端通過(guò)Range頭部請(qǐng)求部分資源時(shí)服務(wù)器會(huì)返回206及對(duì)應(yīng)的內(nèi)容范圍。實(shí)操要點(diǎn)確保你的靜態(tài)文件服務(wù)器或API網(wǎng)關(guān)正確支持并處理Range頭部。3xx重定向響應(yīng)告訴客戶(hù)端“你要的東西不在這去別處找”。重定向分為永久、臨時(shí)等多種用錯(cuò)了可能導(dǎo)致SEO問(wèn)題或循環(huán)跳轉(zhuǎn)。301 Moved Permanently永久重定向。所有請(qǐng)求這個(gè)地址的用戶(hù)代理瀏覽器、爬蟲(chóng)都應(yīng)該更新書(shū)簽。搜索引擎會(huì)將權(quán)重轉(zhuǎn)移到新URL。302 Found臨時(shí)重定向。HTTP/1.0的定義是“Moved Temporarily”但歷史上瀏覽器實(shí)現(xiàn)為GET重定向無(wú)論原請(qǐng)求方法是什么。這可能導(dǎo)致數(shù)據(jù)丟失如POST請(qǐng)求被重定向?yàn)镚ET。307 Temporary Redirect和308 Permanent RedirectHTTP/1.1引入的更明確的狀態(tài)碼。307要求重定向時(shí)方法和實(shí)體不變POST重定向后仍是POST308同理且是永久的?，F(xiàn)代Web開(kāi)發(fā)中應(yīng)優(yōu)先使用307/308來(lái)替代302/301以確保語(yǔ)義準(zhǔn)確。4xx客戶(hù)端錯(cuò)誤錯(cuò)誤出在客戶(hù)端這一邊?？赡苁钦?qǐng)求語(yǔ)法錯(cuò)誤、權(quán)限不足或請(qǐng)求了不存在的資源。這是調(diào)試前端問(wèn)題和進(jìn)行輸入驗(yàn)證的關(guān)鍵。核心邏輯服務(wù)器理解請(qǐng)求但拒絕執(zhí)行。服務(wù)器不應(yīng)該在客戶(hù)端未更改請(qǐng)求的情況下僅因時(shí)間推移就返回2xx。5xx服務(wù)器端錯(cuò)誤錯(cuò)誤出在服務(wù)器這一邊。服務(wù)器在處理有效請(qǐng)求時(shí)發(fā)生了故障。這是運(yùn)維和SRE站點(diǎn)可靠性工程師需要重點(diǎn)關(guān)注的領(lǐng)域。核心邏輯服務(wù)器承認(rèn)錯(cuò)誤或沒(méi)有能力處理請(qǐng)求?？蛻?hù)端可以在稍后重試。2.2 原因短語(yǔ)Reason Phrase的價(jià)值與局限狀態(tài)碼后面的文本如“Not Found”就是原因短語(yǔ)。它主要是為了人類(lèi)可讀程序邏輯判斷應(yīng)完全依賴(lài)于狀態(tài)碼的數(shù)字。不同服務(wù)器對(duì)同一狀態(tài)碼返回的短語(yǔ)可能略有不同如404返回“Not Found”或“File Not Found”所以客戶(hù)端代碼絕不能依賴(lài)于此進(jìn)行邏輯判斷。但在日志分析和人工排查時(shí)它提供了快速直觀(guān)的線(xiàn)索。3. 核心客戶(hù)端錯(cuò)誤4xx深度解析與實(shí)戰(zhàn)應(yīng)對(duì)4xx錯(cuò)誤直接面向用戶(hù)處理得好能提升體驗(yàn)處理不好則導(dǎo)致用戶(hù)流失。3.1 400 Bad Request你的請(qǐng)求“語(yǔ)法”不對(duì)這是最泛泛的客戶(hù)端錯(cuò)誤。意味著服務(wù)器無(wú)法理解請(qǐng)求的語(yǔ)法。常見(jiàn)原因請(qǐng)求體格式錯(cuò)誤例如聲明Content-Type: application/json但發(fā)送的卻是一段無(wú)效的JSON字符串缺少引號(hào)、括號(hào)不匹配。查詢(xún)參數(shù)或路徑參數(shù)格式錯(cuò)誤例如API要求路徑參數(shù)id是整數(shù)/users/123但客戶(hù)端傳入了/users/abc。請(qǐng)求頭缺失或格式錯(cuò)誤例如某些API要求必須攜帶Authorization頭。避坑指南永遠(yuǎn)不要給前端返回裸的400錯(cuò)誤。務(wù)必在響應(yīng)體中提供結(jié)構(gòu)化的錯(cuò)誤信息指明哪個(gè)字段、什么原因。例如{ error: { code: INVALID_REQUEST, message: 請(qǐng)求參數(shù)校驗(yàn)失敗, details: [ {field: email, reason: 格式不正確}, {field: age, reason: 必須為大于0的整數(shù)} ] } }這能極大降低前后端聯(lián)調(diào)的溝通成本。3.2 401 Unauthorized 與 403 Forbidden認(rèn)證與授權(quán)的分野這是最容易混淆的一對(duì)狀態(tài)碼必須嚴(yán)格區(qū)分。401 Unauthorized含義是“未認(rèn)證”Unauthenticated。請(qǐng)求需要用戶(hù)認(rèn)證但客戶(hù)端沒(méi)有提供有效的認(rèn)證憑證如Token、Cookie或憑證已過(guò)期。響應(yīng)必須包含一個(gè)WWW-Authenticate頭部指明如何進(jìn)行認(rèn)證例如WWW-Authenticate: Bearer realmapi。403 Forbidden含義是“未授權(quán)”Unauthorized。服務(wù)器理解請(qǐng)求且客戶(hù)端已成功認(rèn)證但該用戶(hù)沒(méi)有執(zhí)行此操作的必要權(quán)限。例如普通用戶(hù)嘗試訪(fǎng)問(wèn)管理員后臺(tái)API。實(shí)戰(zhàn)場(chǎng)景用戶(hù)登錄后嘗試刪除他人的文章。流程應(yīng)該是1) 檢查是否有登錄憑證Token- 無(wú)則4012) 驗(yàn)證Token有效 - 無(wú)效則4013) 檢查該用戶(hù)是否有權(quán)刪除此文章 - 無(wú)則403。3.3 404 Not Found不僅僅是“找不到”404表示服務(wù)器無(wú)法找到請(qǐng)求的資源。除了字面意思它還被廣泛用于保護(hù)性設(shè)計(jì)資源確實(shí)不存在請(qǐng)求的URL路徑錯(cuò)誤。隱藏資源存在性為了防止信息泄露當(dāng)用戶(hù)請(qǐng)求一個(gè)其無(wú)權(quán)知道的資源時(shí)例如通過(guò)ID枚舉其他用戶(hù)的數(shù)據(jù)也返回404而不是403。這樣攻擊者無(wú)法區(qū)分“資源不存在”和“無(wú)權(quán)訪(fǎng)問(wèn)”。API版本化請(qǐng)求了一個(gè)已廢棄或尚未發(fā)布的API端點(diǎn)。運(yùn)維心得監(jiān)控404錯(cuò)誤率非常重要。突然飆升的404率可能意味著前端資源部署失敗JS/CSS文件404、搜索引擎爬蟲(chóng)抓取了錯(cuò)誤鏈接、或者有惡意掃描探測(cè)行為。3.4 429 Too Many Requests流量控制的哨兵這是HTTP/1.1標(biāo)準(zhǔn)中用于速率限制Rate Limiting的狀態(tài)碼。當(dāng)客戶(hù)端在單位時(shí)間內(nèi)發(fā)送了過(guò)多請(qǐng)求時(shí)服務(wù)器返回429。響應(yīng)頭通常應(yīng)包含Retry-After告訴客戶(hù)端多久后可以重試可以是秒數(shù)也可以是一個(gè)HTTP日期。實(shí)現(xiàn)策略令牌桶算法一個(gè)常見(jiàn)的實(shí)現(xiàn)方式。系統(tǒng)以一個(gè)固定速率向桶中添加“令牌”每個(gè)請(qǐng)求需要消耗一個(gè)令牌。桶滿(mǎn)則令牌溢出丟棄。請(qǐng)求到來(lái)時(shí)如果有令牌則通過(guò)否則拒絕429。分層限流可以對(duì)不同API路徑、不同用戶(hù)等級(jí)設(shè)置不同的限流閾值。分布式限流在微服務(wù)架構(gòu)下需要使用Redis等中心化存儲(chǔ)來(lái)協(xié)同多個(gè)服務(wù)實(shí)例的計(jì)數(shù)。4. 核心服務(wù)端錯(cuò)誤5xx診斷與高可用設(shè)計(jì)5xx錯(cuò)誤是系統(tǒng)穩(wěn)定性的“紅燈”需要立即響應(yīng)。4.1 500 Internal Server Error萬(wàn)能的“背鍋俠”最令人頭疼的錯(cuò)誤。它表示服務(wù)器遇到了一個(gè)未曾預(yù)料的狀況導(dǎo)致其無(wú)法完成請(qǐng)求。這通常意味著應(yīng)用程序代碼拋出了未捕獲的異常。排查黃金步驟立即查看應(yīng)用日志尋找異常堆棧跟蹤Stack Trace。這是定位問(wèn)題的第一手資料。檢查依賴(lài)服務(wù)數(shù)據(jù)庫(kù)連接是否正常緩存服務(wù)Redis是否可達(dá)第三方API調(diào)用是否超時(shí)或失敗檢查資源服務(wù)器磁盤(pán)是否已滿(mǎn)內(nèi)存是否耗盡OOM檢查近期變更是否剛剛進(jìn)行了代碼部署、配置更新或數(shù)據(jù)庫(kù)遷移核心防御永遠(yuǎn)不要將詳細(xì)的錯(cuò)誤信息如數(shù)據(jù)庫(kù)錯(cuò)誤、代碼行數(shù)暴露給最終用戶(hù)。在生產(chǎn)環(huán)境中應(yīng)配置全局異常處理器捕獲所有未處理異常記錄到日志并向用戶(hù)返回一個(gè)友好的、信息模糊的500錯(cuò)誤頁(yè)面。詳細(xì)的錯(cuò)誤信息只應(yīng)在內(nèi)部日志或開(kāi)發(fā)/測(cè)試環(huán)境中出現(xiàn)。4.2 502 Bad Gateway / 503 Service Unavailable / 504 Gateway Timeout網(wǎng)關(guān)與負(fù)載均衡器的“三劍客”這三個(gè)錯(cuò)誤在現(xiàn)代分布式架構(gòu)尤其是使用了Nginx、API Gateway、負(fù)載均衡器中極為常見(jiàn)。502 Bad Gateway作為代理或網(wǎng)關(guān)的服務(wù)器如Nginx從上游服務(wù)器如你的應(yīng)用服務(wù)器Tomcat、Node.js接收到了一個(gè)無(wú)效的響應(yīng)。例如上游服務(wù)器進(jìn)程崩潰返回了一段HTML錯(cuò)誤信息而不是有效的HTTP響應(yīng)。503 Service Unavailable服務(wù)器當(dāng)前無(wú)法處理請(qǐng)求例如因維護(hù)或超載而停機(jī)。這個(gè)響應(yīng)是臨時(shí)的通常應(yīng)伴隨Retry-After頭部。這有時(shí)是一種主動(dòng)的流量控制手段例如在熔斷器Circuit Breaker開(kāi)啟時(shí)網(wǎng)關(guān)直接返回503避免雪崩。504 Gateway Timeout代理或網(wǎng)關(guān)在等待上游服務(wù)器響應(yīng)時(shí)超時(shí)。例如Nginx配置的proxy_read_timeout默認(rèn)60秒如果應(yīng)用服務(wù)器處理某個(gè)請(qǐng)求超過(guò)60秒未返回Nginx就會(huì)向客戶(hù)端返回504。診斷流程圖客戶(hù)端收到5xx - 是502/503/504嗎 - 是問(wèn)題很可能出現(xiàn)在網(wǎng)絡(luò)邊界網(wǎng)關(guān)、負(fù)載均衡器、反向代理。 - 檢查網(wǎng)關(guān)日志如Nginx的error.log。 - 檢查上游應(yīng)用服務(wù)器是否健康進(jìn)程存活、端口監(jiān)聽(tīng)。 - 檢查網(wǎng)絡(luò)連通性和防火墻規(guī)則。 - 檢查網(wǎng)關(guān)的超時(shí)配置proxy_connect_timeout, proxy_read_timeout等是否合理。 - 否是500問(wèn)題很可能出現(xiàn)在應(yīng)用服務(wù)器內(nèi)部。 - 聚焦應(yīng)用日志和資源監(jiān)控。4.3 其他5xx錯(cuò)誤501 Not Implemented服務(wù)器不支持完成請(qǐng)求所需的功能。例如客戶(hù)端向服務(wù)器發(fā)送了一個(gè)PATCH請(qǐng)求但服務(wù)器并未實(shí)現(xiàn)PATCH方法。505 HTTP Version Not Supported服務(wù)器不支持請(qǐng)求中使用的HTTP協(xié)議版本。5. 狀態(tài)碼在A(yíng)PI設(shè)計(jì)、監(jiān)控與調(diào)試中的高級(jí)應(yīng)用理解了狀態(tài)碼本身更重要的是如何在工程實(shí)踐中用好它們。5.1 RESTful API設(shè)計(jì)規(guī)范在設(shè)計(jì)API時(shí)狀態(tài)碼是契約的重要組成部分。GET /resources/{id}成功 -200 OK資源不存在 -404 Not Found無(wú)權(quán)限 -403 Forbidden。POST /resources創(chuàng)建成功 -201 Created附Location頭請(qǐng)求體無(wú)效 -400 Bad Request沖突如唯一鍵重復(fù)-409 Conflict。PUT /resources/{id}更新成功返回完整資源-200 OK更新成功不返回內(nèi)容-204 No Content創(chuàng)建了新資源 -201 Created。DELETE /resources/{id}刪除成功 -204 No Content資源不存在 -404 Not Found冪等性考慮刪除不存在的資源也算成功業(yè)界有爭(zhēng)議通常返回204或404均可但需保持一致。PATCH /resources/{id}部分更新成功 -200 OK或204 No Content。一致性是關(guān)鍵整個(gè)項(xiàng)目或團(tuán)隊(duì)必須對(duì)相同語(yǔ)義的操作返回相同的狀態(tài)碼這能極大降低客戶(hù)端集成的復(fù)雜度。5.2 監(jiān)控告警體系建設(shè)狀態(tài)碼是系統(tǒng)健康的晴雨表必須納入監(jiān)控。關(guān)鍵儀表盤(pán)整體錯(cuò)誤率(4xx5xx) / 總請(qǐng)求數(shù)。設(shè)定閾值告警。5xx錯(cuò)誤率單獨(dú)監(jiān)控直接反映后端服務(wù)可用性。關(guān)鍵端點(diǎn)錯(cuò)誤率對(duì)登錄、支付等核心接口單獨(dú)監(jiān)控其非2xx響應(yīng)比例。4xx分類(lèi)監(jiān)控突然增多的401可能意味著Token刷新邏輯有問(wèn)題暴增的404可能意味著有爬蟲(chóng)或前端發(fā)布故障。鏈路追蹤集成在微服務(wù)架構(gòu)下將請(qǐng)求鏈路上每個(gè)服務(wù)返回的狀態(tài)碼記錄在鏈路追蹤系統(tǒng)如Jaeger, SkyWalking中可以快速定位故障節(jié)點(diǎn)。智能告警不要只對(duì)“有錯(cuò)誤”告警。更高級(jí)的做法是使用同比/環(huán)比告警例如“5分鐘內(nèi)的5xx錯(cuò)誤數(shù)量比前一個(gè)小時(shí)同期增長(zhǎng)了300%”這能更早發(fā)現(xiàn)潛在問(wèn)題。5.3 前端錯(cuò)誤處理與用戶(hù)體驗(yàn)優(yōu)化前端不能僅僅把非2xx響應(yīng)當(dāng)成錯(cuò)誤彈窗。結(jié)構(gòu)化錯(cuò)誤響應(yīng)與后端約定統(tǒng)一的錯(cuò)誤響應(yīng)格式如前文400示例前端可以解析并展示友好的、指導(dǎo)性的錯(cuò)誤信息。狀態(tài)碼驅(qū)動(dòng)的用戶(hù)引導(dǎo)收到401自動(dòng)跳轉(zhuǎn)到登錄頁(yè)或觸發(fā)Token刷新流程。收到403顯示“權(quán)限不足”提示并隱藏或禁用相關(guān)操作按鈕。收到404展示精心設(shè)計(jì)的404頁(yè)面提供導(dǎo)航回首頁(yè)或搜索功能。收到429或503顯示“操作過(guò)于頻繁請(qǐng)稍后再試”或“系統(tǒng)維護(hù)中”并禁用重試按鈕一段時(shí)間。重試策略對(duì)于5xx錯(cuò)誤和網(wǎng)絡(luò)錯(cuò)誤可以實(shí)現(xiàn)指數(shù)退避重試機(jī)制。但對(duì)于4xx錯(cuò)誤除429外絕不應(yīng)自動(dòng)重試因?yàn)殄e(cuò)誤是由無(wú)效請(qǐng)求引起的重試無(wú)用。6. 常見(jiàn)問(wèn)題排查與疑難場(chǎng)景實(shí)錄在實(shí)際工作中一些狀態(tài)碼相關(guān)的問(wèn)題非常棘手。6.1 為什么我的請(qǐng)求在瀏覽器顯示為“CORS錯(cuò)誤”而不是狀態(tài)碼這是一個(gè)經(jīng)典問(wèn)題。瀏覽器因?yàn)橥床呗詴?huì)先發(fā)起一個(gè)“預(yù)檢請(qǐng)求”O(jiān)PTIONS方法。如果這個(gè)預(yù)檢請(qǐng)求失敗例如服務(wù)器未返回正確的CORS頭部瀏覽器會(huì)直接在控制臺(tái)報(bào)CORS錯(cuò)誤并阻止實(shí)際的請(qǐng)求發(fā)出因此你根本看不到業(yè)務(wù)請(qǐng)求的真實(shí)狀態(tài)碼可能是401、403或500。排查時(shí)務(wù)必在Network標(biāo)簽頁(yè)中查看OPTIONS請(qǐng)求的響應(yīng)確保Access-Control-Allow-Origin,Access-Control-Allow-Methods,Access-Control-Allow-Headers等頭部配置正確。6.2 負(fù)載均衡器健康檢查返回200但真實(shí)請(qǐng)求卻返回502健康檢查端點(diǎn)如/health通常設(shè)計(jì)得非常簡(jiǎn)單只檢查應(yīng)用進(jìn)程是否存活、數(shù)據(jù)庫(kù)連接是否通。它返回200只表示“進(jìn)程還在”。但當(dāng)真實(shí)請(qǐng)求到來(lái)時(shí)可能因?yàn)閼?yīng)用內(nèi)部依賴(lài)故障某個(gè)特定的第三方服務(wù)接口掛掉。資源死鎖數(shù)據(jù)庫(kù)連接池耗盡。特定路由問(wèn)題某個(gè)控制器代碼存在Bug。解決方案實(shí)現(xiàn)分層的健康檢查。一個(gè)基礎(chǔ)的liveness探針檢查進(jìn)程和一個(gè)更全面的readiness探針檢查所有關(guān)鍵依賴(lài)。負(fù)載均衡器應(yīng)使用readiness探針來(lái)決定是否轉(zhuǎn)發(fā)流量。6.3 如何區(qū)分“用戶(hù)不存在”和“密碼錯(cuò)誤”從安全角度為了避免用戶(hù)名枚舉攻擊在登錄接口中無(wú)論是用戶(hù)名不存在還是密碼錯(cuò)誤都應(yīng)該返回401 Unauthorized并附上統(tǒng)一的模糊提示如“用戶(hù)名或密碼錯(cuò)誤”。但在內(nèi)部日志中必須記錄詳細(xì)的失敗原因如USER_NOT_FOUND,INVALID_PASSWORD以便安全審計(jì)和運(yùn)營(yíng)分析。6.4 文件上傳時(shí)遇到413 Payload Too Large這個(gè)狀態(tài)碼很直觀(guān)表示請(qǐng)求實(shí)體過(guò)大超過(guò)了服務(wù)器的處理能力。處理方式前端預(yù)防在上傳前檢查文件大小。后端配置在Web服務(wù)器Nginx調(diào)整client_max_body_size在應(yīng)用框架如Express調(diào)整 body parser 的限制。友好響應(yīng)返回413時(shí)可以在響應(yīng)頭Retry-After或響應(yīng)體中提示允許的最大文件大小。狀態(tài)碼的世界遠(yuǎn)不止這些像418 I‘m a teapot這樣的彩蛋碼也偶爾可見(jiàn)。但萬(wàn)變不離其宗理解其分類(lèi)哲學(xué)和設(shè)計(jì)意圖就能在紛繁復(fù)雜的網(wǎng)絡(luò)問(wèn)題中迅速定位方向。最后分享一個(gè)我的習(xí)慣在設(shè)計(jì)和評(píng)審API時(shí)我會(huì)畫(huà)一張狀態(tài)碼轉(zhuǎn)換圖明確每個(gè)端點(diǎn)在各種情況下應(yīng)該返回什么碼。這份文檔后來(lái)成了團(tuán)隊(duì)前后端協(xié)作和測(cè)試用例編寫(xiě)最重要的依據(jù)之一省去了無(wú)數(shù)扯皮的時(shí)間。把狀態(tài)碼用對(duì)、用準(zhǔn)是一個(gè)工程師專(zhuān)業(yè)性的重要體現(xiàn)。