SocketTimeoutException不是错误而是网络通信中预期内的信号，关键在区分connect超时（应快速失败）与read超时（可重试+延时），并按依赖等级分层设置合理超时值，配合幂等控制与可观测性分析。

SocketTimeoutException 不是程序错误，而是网络通信中必须面对的正常信号。关键在于把“连不上”和“连上了但没回数据”分开处理——前者要快失败、换地址或告警；后者才考虑重试、延时、降级。

连接超时（connectTimeout）：连不上就别等

发生在 TCP 三次握手阶段，比如目标机器宕机、端口未监听、防火墙拦截、DNS 解析失败。这类问题加长超时毫无意义，只会拖慢整体响应。

• 建议值：500ms～3s，高可用场景可设为 1s 内
• 触发后应立即切换备用节点、触发告警，或快速返回兜底数据
• HttpURLConnection 中用 setConnectTimeout() 设置；原生 Socket 用 connect(addr, timeout)

读取超时（readTimeout）：连上了但卡住了

连接已建立，服务端迟迟不返回数据。常见于下游慢查询、线程阻塞、GC 停顿、资源争用等。这时延长超时+有限重试才有价值。

• 建议值：根据下游 SLA 设定，如 99% 响应在 800ms 内，则 readTimeout 可设为 2～3s
• 捕获异常后可配合指数退避（如 1s、2s、4s）+ 随机抖动，避免重试风暴
• HttpURLConnection 中用 setReadTimeout()；原生 Socket 在 connect() 后调用 setSoTimeout()

业务逻辑中如何差异化响应

不能所有超时都走同一套重试或降级路径。需结合依赖等级、幂等性、用户感知来判断：

• 强依赖且接口幂等 → 可重试 2～3 次，带唯一请求 ID 防重
• 弱依赖或非核心链路（如埋点、日志上报）→ 直接丢弃，不重试
• 前端直连的关键接口（如登录、支付）→ 连接超时走本地缓存或友好提示；读取超时可降级为“稍后重试”按钮
• 后台任务类调用 → 记录失败并进延迟队列，避免阻塞主流程

可观测性与持续优化

只设超时不够，还要能定位是哪一类超时占主导：

• 在日志中明确标记超时类型（connect-timeout / read-timeout）
• 监控两类超时的 P95/P99 分布，若 connectTimeout 突增，优先查网络或服务注册状态
• 搭配 Wireshark 或 tcpdump 抓包验证三次握手是否完成，快速区分是网络层还是应用层问题