1. 接口超时概述：什么是接口超时、超时的影响、常见超时类型

到底什么是接口超时？

说白了，就是客户端发了个请求，眼巴巴等着服务器回话，结果到了约定的时间服务器没搭理它。举个例子——你跟同事喊了一声“帮我查下这个订单”，然后站在原地等回复，10秒过去了，他还在忙别的，这就是超时。

我个人的理解更直白：超时 = 预期等待的截止时间到了，但响应还没到。在技术层面，这个“截止时间”就是 timeout 参数，不管你在 HTTP 层面设了 3 秒，还是 Dubbo 调用设了 5 秒，一旦超时，客户端直接抛出异常，不再傻等。

我在项目中遇到过几次让人印象深刻的超时——有一次线上告警说“用户下单失败”，查日志发现所有调用都在 2 秒整断掉，一开始以为是网络问题，后来才闹明白是数据库连接池被打满了，请求在池外排队超时了。

超时的影响，比你想的严重

很多人觉得超时不就是报个错嘛，重试一下就好。其实不然。我总结了几类常见影响，你看看有没有踩过类似的坑：

影响层面	具体表现	后果
用户体验	页面白屏、按钮转圈、一直加载	用户流失、满意度暴跌
业务连续性	交易中断、订单状态不一致	资金损失、客诉涌入
系统资源	线程池占满、连接泄漏	雪崩式不可用
排查成本	日志碎片多、告警噪声大	研发通宵救火

嗯，这里要注意一个现象：超时一旦开始成片出现，往往不是单点问题。你想想看，如果你只盯着一两个超时日志去修，很容易忽略背后的公共依赖层——比如共享的 Redis 集群或者网关。

三种最常见的超时类型

其实接口超时不能笼统地当成一种错误，内部有完全不同的原因和排查路径。我习惯把它们分成三大类：

1. 网络层超时

说白了就是 包没到对方手里，或者对方的包没回来。常见于：

• 物理网线断开、光模块故障
• 防火墙丢包、限流
• DNS 解析慢或失败
• TCP 握手三次或者挥手四次被中间设备阻断

怎么区分？看 connect timeout 和 socket timeout。前者连都连不上，后者连上了但数据迟迟不读/不写。我给大家一个实用技巧：抓包看 SYN、SYN-ACK、ACK 三个报文是否完整，缺了就是网络层问题。

2. 服务端处理超时

请求已经到了服务端，但服务端忙着干啥呢？常见原因：

• 业务逻辑太慢（比如循环查询数据库没加索引）
• 线程池满了，请求排队
• 第三方外部调用拖慢了主线程
• GC 停顿导致线程阻塞

这类超时的典型特征：客户端设置的 read timeout 到了，但服务端日志里能看到请求确实被接收了，并且正在处理中。

3. 配置/框架层超时

这个比较隐蔽，简单说就是 超时时间设错了。常见的坑：

• 客户端超时设得比服务端处理时间还短（上面那个例子）
• 网关层超时小于子服务超时，导致网关代报超时
• 连接池超时与接口超时混用，逻辑混乱
• HTTP 客户端默认超时是 0（永不超时），而换了框架后忘了显式设置

你想想看，如果代码里一个 RestTemplate 不设超时，调用挂住之后整个线程池都被耗光，你就只能重启了。我有一次凌晨三点爬起来就是因为这个。

一张图看清超时全貌

下面这张 SVG 把三种超时类型以及它们的影响范围串起来了，你可以对照自己的排查路径来用。