做微服务开发，几乎所有人都配置过接口超时。
大多数项目的逻辑很简单：yml里写死timeout，比如3000毫秒，就默认接口只要3秒内跑完就绝对不会超时。
但线上经常出现一种很懵的情况：接口实际执行耗时只有几百毫秒，日志完整、业务正常落地，调用方却直接报 RPC 超时。
不是偶发一两次，是随机抽风、无规律、流量越高越频繁。
问题根本不在业务耗时，在队列排队
很多人忽略了一个关键点：RPC超时时间，包含"排队时间 + 执行时间"。
微服务线程池核心线程有限，突发流量、瞬时请求高峰，请求会先进入队列排队。
如果队列积压严重，请求还没轮到执行，光排队就耗掉2秒，业务执行再跑几百毫秒。
总耗时超过设定阈值，直接触发超时异常。
服务 CPU、内存、业务耗时看着都很健康，但接口已经大面积超时。
最隐蔽的坑：连接池耗尽导致的假性超时
除了线程池排队，另一个高频诱因是 RPC 连接池满了。
Dubbo、Feign 都有最大连接数限制。高并发、慢接口阻塞、长耗时请求堆积，会快速占满所有连接。
新的请求拿不到连接资源，只能阻塞等待，直到超时。
服务端甚至完全感知不到这个请求，因为请求根本没抵达业务层。
这也是为什么服务端无异常日志，调用方疯狂超时的核心原因。
超时层级不统一，引发连锁超时雪崩
很多项目超时配置极其混乱：网关超时、Feign超时、Dubbo超时、数据库超时，层级大小颠倒。
上层网关超时最短，下层服务超时更长。一旦下游阻塞，上层率先超时断开，下游还在继续执行逻辑。
最终出现：调用方超时报错、下游业务正常执行、数据落库成功，前后数据状态不一致。
更严重的是，超时触发重试，重试叠加流量，直接把本就拥堵的服务彻底打崩。
低耗时慢接口，最容易被忽视
很多人只关注超时量大的慢接口，忽略大量几十毫秒的小接口。
小接口 QPS 极高，瞬时流量密集，线程切换频繁，极易瞬间打满线程池。
看似最快的接口，反而最容易引发排队超时，这是很多团队排查的盲区。
正确的稳定性优化思路
- 分层合理配置超时：网关超时 < 调用方超时 < 服务方超时，杜绝逆向超时导致的脏数据。
- 优化线程池与队列：拒绝无脑加大队列，队列过长只会掩盖拥堵问题，适当限流、快速失败更保稳。
- 监控排队耗时：不只要监控业务执行耗时，重点监控线程池排队、连接池占用、队列积压。
- 超时接口禁止无脑重试：高拥堵场景重试是灾难，配合幂等、熔断、降级，才能稳住流量。
结语
线上绝大多数 RPC 随机超时，和业务代码无关，全是资源调度和流量模型问题。
单纯调大超时时间治标不治本，只会让积压更严重、雪崩来的更猛。
真正的服务稳定，从来不是靠拖慢超时，而是靠限流、排队、熔断、分层配置的全方位兜底。