从一次接口超时看后端排查顺序

接口超时最怕一上来就猜原因。数据库慢、缓存抖动、下游服务不可用、线程池打满、网关限流，都可能表现成相似的现象。更稳的做法是先把问题从一团雾拆成可验证的几条线。

先确认影响面

我会先确认是单个接口慢，还是一类接口都慢；是所有用户都受影响，还是只有特定账号、特定参数、特定时间段受影响。这个步骤不是走流程，而是在缩小搜索范围。

如果只有一个接口慢，重点看接口内部链路。如果同一服务下多个接口同时变慢，要看公共依赖，比如数据库连接池、缓存、远程服务、机器资源和网关链路。

排查时要把一次请求拆成入口、业务处理、数据访问、远程调用、响应返回几个阶段。日志里最好能带上 traceId，这样可以沿着同一个请求把各阶段串起来。

没有 traceId 时，只能靠时间窗口和关键字段拼线索，效率会差很多。这个问题也提醒我：可观测性不是线上出事后才补的东西，而是开发阶段就应该考虑的工程能力。

定位瓶颈时，我不会只看一条慢日志。单条日志只能说明这次请求慢了，不能说明系统性原因。更可靠的做法是把慢请求样本、错误日志、依赖服务状态、数据库慢查询、应用资源状态放在一起看。

如果确认是数据库慢，再进入 SQL 和索引分析；如果是远程调用慢，就看超时配置、重试策略和下游状态；如果是应用内部慢，就看线程池、锁等待和对象创建等问题。

接口超时排查的重点不是记住某个命令，而是形成顺序：先定影响面，再还原链路，最后验证瓶颈。这样的排查方式能减少误判，也更容易把经验沉淀成团队可复用的检查清单。