你写了个小程序调天气数据，页面转圈半天没反应；公司后台突然报错“请求超时”，订单卡在支付环节；甚至刷个网页，加载图标一直打转——这些都可能跟 API 接口请求超时有关。
1. 服务端处理太慢
对方服务器扛不住了。比如小公司用的共享云主机，一到促销高峰，CPU 直接飙到98%，你发过去的请求排队等了3秒还没开始执行，而你的客户端只设了2秒超时，啪一下就断了。
2. 网络链路不稳定
从你手机/电脑出发，经过Wi-Fi路由器、运营商基站、骨干网、CDN节点，再到目标服务器，中间任何一环抖动或丢包，都可能拖长响应时间。特别是用4G/5G切换时，IP临时变化，TCP重连就得耗掉几百毫秒。
3. 客户端超时设置太短
很多开发者图省事，直接写死 timeout: 1000（单位毫秒），也就是1秒。但真实场景里，查一次用户积分+验证权限+拉取头像，三步串行下来轻松破1.5秒。结果不是接口慢，是你自己掐得太狠。
4. DNS解析卡住了
你以为请求是从域名发出的？其实第一步是把 api.example.com 翻成 IP 地址。如果本地 DNS 服务器响应慢，或者 hosts 被误改、DNS 缓存污染，光解析就卡住800ms，后面根本没机会跑。
5. 防火墙或代理偷偷拦截
公司内网常用透明代理，有些会默认对非标 User-Agent 或非常规请求头（比如带 Postman/Insomnia 标识）限速；校园网或公共 Wi-Fi 有时还会对 HTTPS 的 SNI 字段做策略过滤，导致 TLS 握手失败重试，白白浪费超时时间。
怎么快速判断？
打开浏览器开发者工具 → Network 标签页 → 找那个失败的请求 → 看 Timing 里的 “Waiting (TTFB)” 是不是特别长（比如 >2s）。如果是，大概率是服务端或网络问题；如果 “DNS Lookup” 或 “Connect” 时间异常高，就该查本地网络环境了。
命令行党可以试试：
curl -v https://api.example.com/v1/data --connect-timeout 3 --max-time 5