📚 课程目录第2章超时参数概述与重要性

超时参数到底是什么？为什么它那么重要？

说白了，超时参数就是给网络请求定一个“等待期限”。你在代码里发起一次 HTTP 调用、数据库查询或者 RPC 请求，总不能无限等下去吧。我见过太多生产事故，根源都是“没人给请求设个闹钟”。

个人习惯，每接手一个新项目，第一件事就是翻配置里有没有 timeout 关键字。只要发现哪个远程调用没设超时，我就立刻补上——这不是小题大做，是吃过亏才长记性。

超时参数怎么分类？

日常开发里，我们主要关心两类超时：

连接超时（Connect Timeout）：客户端尝试跟服务端建立 TCP 连接时，最多愿意等多久。过了这个时间没连上，直接报错，别傻站着。
读取超时（Read Timeout / Socket Timeout）：连接已经建立，但在读响应数据时，两个数据包之间的最大空闲等待时间。服务端半天不发数据，客户端不能一直吊死。

有的框架还会提 写入超时（Write Timeout），不过核心还是上面两个。

我遇到的一个案例：有一次线上接口偶尔卡死，排查发现是第三方支付回调慢，而我们的 HTTP 客户端只设了连接超时（2秒），读取超时根本没设。结果连接很快建好，但对方迟迟不回 body，线程就堵在那里。补上读取超时 5 秒后，问题立刻消失。

超时类型	定义	常见默认值	影响
连接超时	等待 TCP 握手完成的最大时间	通常 1～5 秒	连不上快速失败，避免线程堆积
读取超时	两次数据包到达的最大间隔	通常 5～30 秒	避免服务端不响应时客户端死等
写入超时	发送请求数据时的最大等待时间	通常 5～10 秒	防止本地写入缓冲区满时卡住

不设超时的风险有多大？

你想想看，一个请求没有超时限制，会发生什么？

资源泄露：线程、连接、内存全占着不放。一个慢请求就能拖垮整个线程池。
系统雪崩：下游服务挂了，上游所有调用方都堵在等待上，最终 cascading failure 全线崩溃。
用户感知极差：App 或网页转圈圈，十几秒甚至几分钟没反应。用户直接卸载。
难以排查：没有超时日志，你根本不知道哪个环节在慢。我曾经排查过一个持续 30 分钟的慢接口，最后发现是内网 DNS 解析卡了，而 HTTP 客户端没有任何超时兜底。

避坑指南：我曾经在一个金融项目里，同事为了“保险”把所有超时都设成 0（0 表示无限等待）。结果数据库主库宕机 10 秒，整个应用线程全部 hang 住，30 秒后 OOM。嗯，从那以后我强制规定：超时值必须是正整，并且不能超过业务 SLA 的 3 倍。

超时参数的核心逻辑图

下面这张图帮你把整个超时体系的分类、位置、风险串联起来。注意看每个超时点对应的“瓶颈”。

怎么配置才合理？

没有万能值，但有几个指导原则：

连接超时：建议 1～3 秒。内网服务可以设 500ms～1s，外网 2～3s。超过 5 秒基本说明网络或对方挂了，等也没用。
读取超时：根据接口 95 分位响应时间来定。我一般取 p95 × 2 或 p99 × 1.5。例如接口平均 200ms，p95 是 800ms，读取超时可设 2 秒。
写入超时：通常与读取超时相同，或者稍小一点。大数据量上传的 API 可以适当放宽。

一个小技巧：在配置中心（比如 Apollo / Nacos）里管理超时值，不要硬编码。我习惯给每个上游调用单独配一组超时，线上可以动态调整，不需要重启服务。

代码示例（Python requests 库）

import requests

try:
    resp = requests.get(
        'https://api.example.com/data',
        timeout=(3.05, 27)   # (连接超时, 读取超时)
    )
    print(resp.status_code)
except requests.exceptions.ConnectTimeout:
    print("连接超时，请检查网络或服务端")
except requests.exceptions.ReadTimeout:
    print("读取超时，服务端响应太慢")

注意 timeout=(3.05, 27) 这个写法。第一个小数是连接超时（秒），第二个是读取超时。为什么要写 3.05？因为某些代理或 DNS 解析的默认行为，整数 3 可能被内部四舍五入成 2.x，留一点点余量更稳妥。这个细节是我在压测时发现的，也算一个冷知识吧。

常见陷阱一览

陷阱	表现	正确做法
只设连接超时，不设读取超时	连接很快，读取永远死等	两者都要设，且读取超时不能为 0
超时值设置过大（如 60秒）	虽然不会死等，但积累的慢请求仍会拖垮系统	根据 p95 / p99，不宜超过 10秒
所有接口共用同一超时值	大文件上传接口超时，小查询接口也在干等	按接口特点分别配置
超时后不重试或重试策略错误	一次超时就放弃，或无限重试导致雪崩	配合指数退避 + 有限次重试（最多 2-3 次）