网页或 API 运行缓慢 — 你如何找到原因？

Question

Accepted Answer

**不要猜测 — 先测量。** 缓慢可能来自客户端、网络、服务器或数据库。有条不紊的方法能找出时间花在*哪里*，然后修复**最大的瓶颈**，而不是随意优化。

## 有条不紊的步骤

```text
1. MEASURE → where is the time spent? client render, network, server, DB?
2. REPRODUCE → confirm it reliably (same endpoint, payload, user)
3. TRACE → use APM/distributed traces to find the slow span
4. CHECK RECENT CHANGES → deploys, config, traffic, data growth
5. ISOLATE → layer by layer, narrow to one component
6. FIX the biggest contributor → re-measure to confirm
```

## 先测量：时间花在哪里？

使用浏览器 **Network/Performance** 标签和服务器 **timing** 来分解总耗时。一个有用的分解方式：

```text
Total 1200ms =
  DNS/connect      20ms
  server TTFB     900ms   ← the bottleneck is server-side
  download         80ms
  client render   200ms
```

查看 **百分位数，而非平均值**：**p50**（典型用户）vs **p99**（最坏情况）。快速的 p50 伴随缓慢的 p99 指向间歇性问题 — 锁竞争、冷缓存、慢 DB 副本或 GC 暂停 — 而非普遍问题。

## 追踪缓慢的 span

APM 工具（traces）精确显示请求中时间花费的位置：

```text
GET /orders                       950ms
  ├─ auth check                    10ms
  ├─ SELECT orders                 30ms
  └─ loop: SELECT user per order  900ms   ← N+1 query, the real cause
```

trace 直指罪魁祸首的调用。然后检查 **最近的变更** — 一次部署、缺失的索引或 10 倍数据增长往往解释了突然的性能下降。

## 为什么这很重要

猜测浪费数小时在错误的层优化。先测量、追踪缓慢的 span 并查看 **p50 vs p99** 将模糊的