4. OkHttp默认超时配置及其在启动场景下的风险归纳

老实说，OkHttp的默认超时参数看着挺友好——connectTimeout 10秒，readTimeout 10秒，writeTimeout 10秒。但一放到启动场景，这些“友好”的默认值反而成了定时炸弹。我踩过好几次坑，今天就帮大家把这些风险彻底捋清楚。

4.1 默认配置一览

先看看OkHttp 4.x版本的默认值（3.x也基本一致）：

OkHttpClient client = new OkHttpClient.Builder()
    .connectTimeout(10, TimeUnit.SECONDS)
    .readTimeout(10, TimeUnit.SECONDS)
    .writeTimeout(10, TimeUnit.SECONDS)
    .build();

这三个超时分别控制什么？

• connectTimeout：建立TCP连接的最大等待时间。包括DNS解析+TCP握手+TLS协商（如果启用HTTPS）。
• readTimeout：从服务器读取数据包之间允许的最大闲置时间。注意是“包之间”，不是总传输时长。
• writeTimeout：向服务器发送数据包之间允许的最大闲置时间。

在正常网络下，10秒绰绰有余。可启动阶段呢？嗯，这里要好好分析一下。

4.2 启动场景的三大“杀手”

我个人的习惯是，把启动阶段的网络请求单独拎出来评估。为什么？因为这时候系统还没完全就绪，有三大典型问题会让默认超时变得非常脆弱。

4.3 风险的核心关联链

启动场景下的超时风险不是孤立的。它们之间存在一个典型的恶化循环：

• 超时后OkHttp默认会重试（retryOnConnectionFailure默认true）。
• 重试又花费10秒，再次超时。
• 主线程如果阻塞等待结果（比如用同步请求或get()），直接ANR。
• 即使异步，回调中触发的UI更新也可能因上下文缺失而崩溃。

你想想看，真正导致崩溃的往往不是超时本身，而是超时后的一连串连锁反应。

我把这个链条画成了下面的结构图，帮助大家直观理解：