接口请求很慢，怎么排查？

详细解析#

第一步：看 Timing，定位阶段#

dns-prefetch、preconnect 的用法见资源提示，DNS 的解析过程见 DNS 解析。

TTFB 长：到服务端找原因#

TTFB 包含服务端处理时间和网络往返时间，大多数情况是服务端处理慢：

• 慢 SQL：缺少索引、扫描的行数多、锁等待
• 依赖的下游服务慢，或者串行调用了多个服务
• 冷启动：Serverless 函数、刚扩容的实例，缓存和连接池还没预热
• 资源不足：CPU 打满、连接池耗尽

排查时看服务端日志里的处理耗时。比如 Nginx 可以记录 $request_time（从读到客户端请求的第一个字节，到响应发送完毕）和 $upstream_response_time（和后端交互的耗时），前者大、后者小，说明时间花在了 Nginx 和客户端之间。再用链路追踪（如 OpenTelemetry、SkyWalking）查看每一段调用的耗时。

还可以用 Server-Timing 响应头把服务端各阶段的耗时带给浏览器，DevTools 的 Timing 面板会直接展示出来：

// Express 示例：记录查库和调用下游服务的耗时（单位：毫秒）
app.get('/api/orders', async (req, res) => {
  const t0 = performance.now()
  const orders = await db.findOrders(req.query)
  const t1 = performance.now()
  const users = await userService.batchGet(orders.map((o) => o.userId))
  const t2 = performance.now()
  res.set('Server-Timing', `db;dur=${(t1 - t0).toFixed(1)}, rpc;desc="user service";dur=${(t2 - t1).toFixed(1)}`)
  res.json({ orders, users })
})

用 curl 分阶段计时#

排除浏览器的影响，直接看各阶段的耗时：

curl -o /dev/null -s -w 'dns: %{time_namelookup}s\nconnect: %{time_connect}s\ntls: %{time_appconnect}s\nttfb: %{time_starttransfer}s\ntotal: %{time_total}s\n' https://api.example.com/orders

dns: 0.012s
connect: 0.045s
tls: 0.120s
ttfb: 0.980s
total: 1.020s

这些时间都是从请求开始累计的，要两两相减：DNS 12 毫秒，TCP 握手 33 毫秒，TLS 握手 75 毫秒，等待首字节 860 毫秒（含一次网络往返），下载 40 毫秒。问题出在服务端。

缩小范围#

• 偶发还是必现：必现的，直接沿着链路查；偶发的，看出问题的时间点是否和流量高峰、定时任务、缓存集中过期、连接池耗尽吻合
• 个别用户还是所有用户：只有某个地区、某个运营商慢，可能是 CDN 节点、跨运营商链路或 DNS 调度的问题（见 CDN 的原理）
• 单个接口还是所有接口：全部都慢，查网络、网关和公共依赖；单个接口慢，查它自己的逻辑和 SQL

看分布，不看平均值#

用前端监控统计接口的耗时，按 P50、P95、P99 看分布，而不是只看平均值（见前端监控）。如果用 Resource Timing 采集跨域接口的分阶段耗时，服务端要返回 Timing-Allow-Origin 响应头，否则拿不到详细数据。

面试官可能追问#

易错点#

• curl -w 输出的是从请求开始累计的时间点，不是各阶段各自的耗时
• TTFB 不等于服务端处理时间，它还包含网络往返
• 本地测试很快，不代表用户那里也快，要看监控里不同地区、运营商和网络环境的数据