在实际线上环境中，接口“偶尔变慢”是一种非常常见、但也最让人头疼的问题。它不是持续性故障，无法稳定复现，压测时一切正常，但用户就是会偶发卡顿。 这类问题，通常不是某一个点“坏了”，而是多个系统环节叠加后的结果。 一、先别急着看代码，从日志开始 排查慢接口，第一步一定是拆解耗时。如果你使用的是 Nginx 反向代理，建议在 access log 中至少记录以下字段： $request_time $upstream_connect_time $upstream_header_time $upstream_response_time 通过这些字段，你可以快速判断问题出在哪一层： connect_time 高：连接池耗尽、DNS、网络问题 header_time 高：后端应用处理慢 response_time 高：后端在“边算边吐数据”，可能是 IO 或流式逻辑问题 很多“接口慢”的问题，到这里就已经能定位 70%。 二、数据库不是慢，而是“偶尔很慢” 数据库最容易被背锅，但真实情况往往是： SQL 本身没问题 在某些参数组合下走了错误索引 或者在高并发下触发了行锁 / gap lock 建议重点排查： 是否存在 IN (...) 参数规模突增 是否使用了 DATE(created_at) 这类函数导致索引失效 是否有统计类 SQL 混在了主流程接口里 一个经验原则：统计 SQL 永远不要和实时接口共用一条链路。 三、连接复用比你想象的重要 在高并发场景下，很多慢请求并不是“算得慢”，而是： HTTP 频繁新建连接 TLS 握手耗时 数据库连接池被打满 如果你使用 Go / PHP / Node： 确认 HTTP Client 是否是单例 数据库连接池参数是否合理 是否存在“每个请求 new client”的写法 这一类问题，通常在 QPS 上来之后才会暴露。 四、结语 “偶尔很慢”的接口，几乎从来不是一个 bug，而是架构边界不清、资源使用不均衡的结果。 排查顺序永远是： 日志 → 网络 → 连接 → SQL → 业务逻辑 顺序对了，问题就已经解决了一半。