在移動應用開發中，網絡請求失敗是最高頻且令人頭疼的問題之一。無論是弱網環境、服務器瞬時波動，還是客戶端線程調度異常，都可能導致請求無響應或數據損壞。面對這類問題，簡單地在UI層彈出一個“網絡錯誤”提示，既無法解決根本問題，也會嚴重傷害用戶體驗。真正工程化的做法，是在底層網絡框架中構建一套嚴謹的重試機制與超時設置策略。這兩者看似獨立，實則相互耦合：超時時間是重試決策的關鍵輸入，而重試行為又必須受到超時總時長的嚴格約束。本文將從實戰角度，拆解如何“寫好”這兩個核心控制點。
很多開發者誤以為超時只是一個“秒數”配置，實際上，一次完整的APP網絡請求包含至少三個獨立的超時維度，必須分別設置，不可混為一談。
連接超時：指客戶端與服務器建立TCP連接的最大等待時間。若在Wi-Fi信號強但網關響應慢的環境中，連接超時極易觸發。該值設置過短（如2秒），在4G/5G網絡下可能因基站切換導致頻繁失敗；設置過長（如30秒），則會阻塞線程池，造成連鎖資源浪費。推薦初始值設定在8~12秒，并允許根據網絡類型（蜂窩/Wi-Fi）動態調整。
讀取超時：指連接建立成功后，等待服務器返回第一個數據包的時間。這并非整個響應體的下載時間，而是首字節的等待時長。讀取超時主要應對的是服務端處理邏輯過慢或數據庫鎖等待問題。建議取值10~15秒，對于文件上傳/下載類接口，則應單獨采用流式進度回調，而非依賴讀取超時控制。
寫入超時：指客戶端向服務端發送請求體的最大時間。在上傳圖片、日志或大文本時，寫入超時尤為關鍵。通常可設為與讀取超時一致，若上行帶寬受限，可適度放寬至20秒。
關鍵原則：總請求耗時 ≠ 連接超時 + 讀取超時。實際超時控制應采用“總超時炸彈”——即從請求發起至收到完整響應的絕對時間上限，通常設置為連接超時與讀取超時之和的1.2~1.5倍。這個總超時是重試機制的“最終紅線”，一旦觸發，無論當前處于第幾次重試，都必須立即終止。
重試并非“失敗就再試一次”這么簡單。不加約束的重試會引發“雪崩效應”：當服務端因負載過高而響應緩慢時，客戶端的重試只會加劇壓力，使恢復時間呈指數增長。因此，重試策略必須遵循以下核心約束：
冪等性校驗：僅對冪等請求（如GET、PUT、DELETE）啟用自動重試。對于POST創建訂單、支付確認等非冪等操作，絕不可自動重試，只能提示用戶手動操作，否則可能導致重復扣款或臟數據。
錯誤碼白名單：并非所有網絡錯誤都值得重試。例如HTTP 401（未授權）、403（禁止訪問）、404（未找到）屬于客戶端邏輯錯誤，重試無效；而503（服務不可用）、504（網關超時）、以及DNS解析失敗、連接重置等網絡層錯誤，才具備重試價值。建議維護一份可重試的錯誤碼集合，并允許業務方覆蓋。
退避策略：固定間隔重試（如每隔3秒重試一次）在并發高時極易造成“驚群效應”。必須采用指數退避加抖動。例如：首次重試延遲1秒，第二次延遲2秒，第三次延遲4秒……同時引入±20%的隨機抖動，避免大量客戶端在同一時刻同時重試。最大重試間隔建議封頂在30秒。
重試次數上限：通常設定為3~5次。超過該次數，應認為網絡環境或服務端存在持續性故障，轉而展示兜底頁面或緩存數據。
超時和重試不能各自為政，它們必須共享同一個“總時間預算”。假設單次請求的連接超時為10秒，讀取超時為12秒，則單次請求的理論最大耗時為22秒。若設定最大重試次數為3次，且采用指數退避（1s、2s、4s），則總耗時為：
(22 + 1) + (22 + 2) + (22 + 4) = 73秒
這顯然不可接受——用戶不可能等待超過一分鐘。正確的做法是引入全局請求超時，例如設為25秒。那么當第一次請求耗時18秒失敗后，第二次重試的退避等待1秒，剩余時間預算僅剩6秒，此時第二次重試的連接超時和讀取超時應被動態壓縮（如連接超時縮短為3秒，讀取超時縮短為3秒），若仍失敗，則第三次重試直接取消，返回“請求超時”錯誤。
這種動態壓縮策略，需要底層網絡庫支持逐次遞減超時或剩余時間切片。工程實現上，可以在每次重試前計算?剩余允許時間 = 全局超時 - 已耗時，再將此剩余時間按比例分配給連接和讀取階段。
除了HTTP狀態碼，還需關注異常類型：
CancellationException：用戶主動取消（如退出頁面），不重試。
InterruptedIOException：線程中斷，不重試。
SocketTimeoutException：超時類異常，視剩余時間決定是否重試。
UnknownHostException：DNS解析失敗，若連續兩次失敗，大概率是網絡不可達，應停止重試并提示檢查網絡開關。
SSLHandshakeException：證書校驗失敗，絕不重試，因為重試無法解決證書問題。
建議在重試攔截器中，設計一個?RetryJudger?類，專門負責判斷當前異常是否可重試。該判斷邏輯應包含：異常類型匹配、當前重試次數、剩余時間預算、當前網絡連接狀態（如是否Wi-Fi）等綜合因子。
技術上的重試和超時，必須與UI表現協同，否則用戶感知到的仍是“卡死”或“閃退”。以下實踐值得采納：
透明重試 vs 顯式重試：首次重試（第1次）應透明靜默執行，不彈出任何加載框，用戶無感知。第2次重試時，可在界面底部展示輕量提示條（非模態），如“網絡較慢，正在重試”。第3次及以上，若仍失敗，則顯示明確的錯誤頁，并提供“手動重試”按鈕，將決策權交還用戶。
取消舊請求：每次發起新重試前，必須取消上一次請求的底層Socket連接和回調，防止內存泄漏和“回調泛濫”。同時清理已注冊的BroadcastReceiver或LiveData觀察者。
隊列化管理：若同時存在多個請求，當檢測到連續3次連接超時后，應主動暫停后續請求隊列，優先發送一個“探測性請求”至健康檢查接口（如?/ping），待探測成功后再恢復隊列。這能有效避免在弱網下大量請求并發阻塞。
寫好重試和超時，不是“一次配置，終身有效”。必須建立監控埋點：
記錄每次重試的觸發原因、重試次數、退避延遲、最終成功/失敗狀態。
按網絡類型（2G/3G/4G/5G/Wi-Fi）統計平均連接超時和讀取超時，定期（如每周）分析P95分位值。
若發現某地區用戶讀取超時占比突增，可通過遠程配置中心動態下調該地區讀取超時閾值（例如從15秒降至8秒），并同步增加重試次數，避免長時間等待。
此外，對于長尾請求（耗時超過P99的請求），應單獨設定“慢請求重試”策略：即便狀態碼為200成功，若耗時超過全局超時的80%，也主動觸發一次“備用路徑重試”（例如切換備用域名或IP），以保證關鍵接口的時效性。
不建議將重試和超時邏輯散落在每個業務ViewModel或Presenter中。正確的做法是：
在網絡基礎層（如OkHttp攔截器鏈或Retrofit CallAdapter）中統一實現重試攔截器。
超時配置以?RequestOptions?對象傳入，每個請求可覆蓋全局默認值，但必須受全局最大總超時約束。
采用責任鏈模式，將“連接超時計算”“讀取超時計算”“重試決策”“退避延遲生成”“剩余時間裁剪”拆分為獨立的Handler，便于單測和迭代。
單元測試時，應模擬?MockWebServer?延時響應、Socket中斷、返回500等場景，驗證重試次數是否正確、退避時間是否符合預期、總超時是否嚴格生效。務必覆蓋“重試過程中用戶退出頁面”的場景，確保協程或RxJava的訂閱被及時釋放。
文件下載：應使用斷點續傳代替重試。每次讀取超時后，記錄已下載字節范圍，重試時攜帶?Range?頭，而非重新下載整個文件。
WebSocket長連接：重連機制不應采用指數退避，而應采用線性退避（每次增加固定秒數，上限60秒），因為長連接重連開銷大，且頻繁重連會耗盡服務端文件描述符。
預請求：在應用啟動時，可發送一個輕量級預熱請求，用于提前探測當前網絡環境的RTT和丟包率，據此動態調整全局超時基值。若預熱請求失敗，可提前降級為離線模式，避免后續大量請求超時。
APP網絡請求的穩定性，很大程度上取決于超時和重試這對“組合拳”是否打得精準。優秀的實現不是追求“永不失敗”，而是保證在失敗發生時，系統能以最小的代價、最短的時間、最友好的方式完成恢復或降級。請始終記住：超時是防御，重試是補救，而用戶體驗才是最終的裁判。務必通過嚴謹的數值模型、充分的異常測試和持續的數據監控，讓這兩項配置隨業務和網絡環境共同進化，而非凝固在代碼注釋中一成不變。
聯系電話