线上有个接口，测试环境跑得好好的，上了生产环境平均响应时间从200毫秒飙到3秒——这种情况你遇到过吗？排查API接口响应慢的问题，最怕的就是没有方法论，东试一下西试一下，浪费半天也没找到根因。
第一步：确认问题边界
拿到一个慢接口，先别急着改代码。问自己三个问题：是所有请求都慢，还是偶发性的慢？是单个接口慢，还是整个服务都慢？是刚上线就慢，还是运行一段时间后才变慢？这三个问题的答案直接决定排查方向。偶发性慢通常是资源竞争或GC导致；单个接口慢多半是业务逻辑或SQL问题；运行一段时间才慢，大概率是内存泄漏或连接池耗尽。
第二步：网络层排查
用curl命令加-w参数看时间拆解：curl -o /dev/null -s -w “DNS:%{time_namelookup} TCP:%{time_connect} TLS:%{time_appconnect} TTFB:%{time_starttransfer} Total:%{time_total}“。重点关注TTFB（首字节时间），如果TTFB就很高，问题在服务端处理；如果TCP连接时间长，可能是网络链路或DNS解析的问题。这一步能帮你排除“不是网络的问题“。
第三步：应用层 profiling
在代码里加埋点，记录每个关键步骤的耗时。Java项目可以用Arthas的trace命令，PHP可以在方法入口出口加microtime()，Node.js可以用clinic.js做火焰图。重点看三个地方：有没有循环里查数据库的N+1问题、有没有大对象序列化耗时、有没有外部HTTP调用没有设超时。实际项目中，外部HTTP调用不设超时是隐性性能杀手，对方服务一旦变慢，你的接口就跟着拖死。
第四步：数据库层分析
开启慢查询日志，阈值设为500毫秒。用EXPLAIN分析慢SQL的执行计划，重点看type字段——如果是ALL说明全表扫描，必须加索引。另外检查索引是否生效，有时候你加了索引但SQL用了函数转换导致索引失效，比如WHERE DATE(create_time)='2024-01-01'这种写法就不会走索引，改成WHERE create_time>='2024-01-01' AND create_time<'2024-01-02'就行。
第五步：形成排查清单
把排查经验沉淀成团队清单：网络层看TTFB、应用层看埋点、数据库看慢查询。每次遇到慢接口，按清单逐项过，半小时内基本能定位。性能优化不是玄学，是系统工程。