上周帮朋友改一个微信小程序，首页老是卡三秒才出来——查日志发现，是调用天气接口时经常超时。他原以为加个 loading 就完事，结果用户等不及直接关掉。接口超时不是报错，但比报错更磨人：没提示、不崩溃、只默默卡住。
先搞清楚超时从哪来
常见场景其实就三种：网络抖动（比如地铁里切4G/5G）、服务端响应慢（对方服务器正扛着大促流量）、你本地代码没设好超时时间。很多同学一上来就怀疑是后端问题，其实八成是自己发起请求时压根没配 timeout。
HTTP 请求里必须写 timeout
以 axios 为例，不加 timeout 的默认行为是「无限等待」：
axios.get('/api/weather?city=shanghai') // ⚠️ 危险！没设超时改成这样才靠谱：
axios.get('/api/weather?city=shanghai', {
timeout: 8000 // 超过8秒直接中断，进 catch
})fetch 也一样，得靠 AbortController：
const controller = new AbortController();
setTimeout(() => controller.abort(), 8000);
fetch('/api/weather?city=shanghai', {
signal: controller.signal
})别光靠重试，得会挑时机
有人一遇到超时就自动重试3次，结果用户点一次按钮，后台收到4个请求。更稳妥的做法是：首次超时后，等500ms再试，且只重试1次；如果是 POST 类操作（比如提交订单），干脆别自动重试，直接提示「网络不稳，请稍后手动重试」。
前端兜底：给用户看得见的反馈
超时不是黑盒。可以在请求发起时显示「正在获取天气…」，超时后立刻换成「暂时无法获取天气，点击重试」，按钮保持可点。别让页面静默空白，那才是用户体验崩盘的开始。
顺手检查下你的文档排版
如果你在写接口文档或内部技术说明，记得把超时参数单独列一栏，标红加粗。我们团队之前就吃过亏——后端写了「建议客户端设置 timeout ≤ 5s」，但埋在接口字段描述第三段里，前端同学根本没看见。现在统一加到每个接口的「调用约束」小标题下，带图标提醒。