接口超时与性能排障：网络、应用、数据库问题怎么区分
一、先说结论
这一篇主要解决三个经常一起出现的线上问题：
- 为什么接口偶发超时，但服务端日志看起来没报错？
- 为什么用浏览器访问正常，但程序里访问超时？
- 线上接口性能差时，怎么区分是网络问题、应用问题还是数据库问题？
如果先把主线压缩成几句话，可以这样记：
- 超时很多时候不是“炸了”，而是“没炸，但慢到别人等不起了”
- 浏览器能访问，不代表程序一定能访问，因为访问条件可能完全不同
- 排查性能问题不能靠猜，要把总耗时拆开，看时间死在哪一段
二、为什么接口偶发超时，但服务端日志看起来没报错
这类问题非常常见，本质上是：
超时是一个观察结果，不一定意味着服务端代码真的抛了异常。
1. 请求只是慢，并没有报错
例如：
- 客户端超时设为 3 秒
- 服务端处理需要 8 秒
那客户端 3 秒就超时了，但服务端第 8 秒可能仍然正常处理完毕。
从服务端角度看，它不是 error，只是：
处理得太晚了。
2. 超时发生在网关、代理或调用方
很多时候不是应用本身先超时，而是：
- Nginx / 网关超时
- RPC 调用方超时
- 浏览器或前端主动放弃等待
这时服务端应用可能仍在继续执行，所以你在服务端日志里看不到明确异常。
3. 下游慢，但主服务只是在等待
比如接口内部卡在：
- 数据库查询
- Redis 调用
- RPC 下游服务
- 第三方 HTTP 请求
如果这些下游没有立刻报错，只是一直卡住，那么主服务线程也只是阻塞等待，不一定会打出 error。
4. 线程池 / 连接池排队太久
请求也可能不是耗在业务逻辑本身，而是耗在：
- 线程池排队
- 数据库连接池等待
- HTTP 连接池耗尽
这种情况下接口整体很慢，但日志里未必有明显异常栈。
三、为什么用浏览器访问正常，但程序里访问超时
这题最重要的理解是：
浏览器和程序访问的“条件”并不一定相同。
1. 浏览器可能走了代理，程序没有
例如在公司网络里：
- 浏览器用了系统代理 / PAC
- 浏览器能正常访问外网
- 程序默认直连，结果被拦截或路由不通
于是就会出现：
- 浏览器正常
- 程序超时
2. DNS 解析结果可能不同
可能出现：
- 浏览器命中了本地缓存
- 程序走了另一套 DNS
- 程序优先走 IPv6
- 浏览器实际走 IPv4
这样两边虽然请求的是同一个域名，但实际落到的目标地址可能不一样。
3. 程序超时配置更激进
程序里常见会设：
- connect timeout 1 秒
- read timeout 2 秒
而浏览器往往更“愿意等”。
所以有些边缘网络抖动场景下，就会表现成：
- 浏览器正常
- 程序超时
4. 浏览器自动带了更多上下文
浏览器访问时通常会自动处理：
- Cookie
- User-Agent
- 认证状态
- 重定向
- 证书信任链
- SNI / ALPN / TLS 兼容细节
而程序如果只是裸请求，缺少这些上下文，也可能导致访问行为完全不同。
5. 运行环境不同
还有一种很现实的情况：
- 浏览器在你的本机
- 程序跑在服务器 / Docker / K8s 里
这时根本就不是同一个网络出口，自然不能简单类比。
四、线上接口性能差时，怎么区分是网络问题、应用问题还是数据库问题
这类题最忌讳“凭感觉猜”。
正确思路是：
先拆链路，再看时间主要耗在哪一段。
1. 先建立链路视角
一个接口请求通常会经过：
客户端 -> 网络传输 -> 网关/负载均衡 -> 应用服务 -> RPC/Redis/DB -> 返回所以性能差可能卡在任意一段。
2. 网络问题的常见特征
更像网络问题时，常见表现是：
- connect time 很高
- DNS 解析慢
- TLS 握手慢
- RTT 高、丢包、抖动大
- 某些机器访问正常，某些机器异常
- 请求在“进服务前”就耗掉很多时间
3. 应用问题的常见特征
更像应用问题时，常见表现是：
- 服务本身 RT 高
- CPU 飙高
- 线程池排队
- GC 停顿明显
- 某段业务逻辑特别慢
- trace 里应用内部方法耗时高
4. 数据库问题的常见特征
更像数据库问题时，常见表现是：
- SQL 执行慢
- 慢查询增多
- 锁等待明显
- 数据库连接池耗尽
- 索引缺失 / 全表扫描
- DB RT、连接数、IO 指标异常
5. 实战排查顺序
通常建议按这个顺序看：
- 先看网关 / 接入层日志和 RT
- 再看应用 trace / 线程池 / CPU / GC
- 再看 RPC / Redis / MQ 等下游依赖
- 最后看数据库慢查询、锁、连接池、执行计划
关键不是“看哪个最可疑”，而是：
谁耗时高，先盯谁。
五、面试里怎么回答会比较顺
如果面试官让你概括这些线上问题，可以这样答：
接口超时不一定意味着服务端代码抛错，很多时候只是某一段链路太慢，调用方先等不起了。例如网关超时、线程池排队、下游数据库或 RPC 卡住、客户端主动放弃等待等，都可能导致“超时但服务端日志没报错”。而浏览器能访问、程序访问超时，则通常说明两者访问条件不同，比如代理、DNS、超时配置、TLS、Cookie 或运行环境不同。线上接口性能差时，关键不是靠猜，而是先把链路总耗时拆开，看时间主要耗在网络、应用还是数据库哪一段，再结合网关日志、trace、线程池、GC、慢查询日志和数据库监控逐层定位。
六、一句话总结
这一组场景题可以压缩成一句话：
线上排障最重要的能力，不是背概念，而是把“超时、慢、失败”拆回到具体链路和具体耗时上。