接口超时，第一件事不是改代码，是判断问题在哪一段。顺序对了，排查能省一半时间。打来电话第一句就问，接口调试先做哪一块最划算。我的建议是，先把最费时间的一环换掉。
先分清是慢还是断
超时有两种，慢慢变慢和突然断开。一直是慢的，多半是性能问题；突然断的，多半是网络或者对方服务的问题。
拿一个固定的请求反复测几次，看耗时是稳定的还是忽高忽低。稳定偏慢和处理不了两回事，方向也不同。
这一步不用工具也能做，多试几次就有感觉。别跳过，跳过容易查错方向。
再看是这边的还是对方的
确定是慢之后，看是自己这边还是对方那边。在自己服务里打日志，看时间花在接收、处理还是返回阶段。
如果自己处理很快，时间都花在等对方，那问题就在对端。这时候改自己的代码没用，要和对方一起看。
我们常遇到的情况是，两边都说自己没问题。这时候把各自的耗时日志摆出来对，往往很快就清楚了。
然后是网络和数据库
排在后面的常见原因是网络和数据库。网络抖动会让请求时快时慢，数据库慢查询会让处理阶段卡住。
网络的问题看丢包和延迟。数据库的问题看慢查询日志，这两处都有现成的工具和日志。
排查有个原则，从外往里一层层剥。先确认边界，再往里查，比一上来就翻代码高效。
怎么减少超时发生
超时排查是事后的事，更该想的是怎么让它少发生。
一个是给关键接口设合理的超时时间，别设成无限等。等不到就早点失败，比一直拖着占资源好。
另一个是把慢的操作挪出去。比如发通知、生成报表这类不急的，后台异步做，别卡在接口里。
还有缓存。同样的数据反复查，缓存一层能省掉很多重复的压力。
上线前也可以压一压。模拟多一点请求看看接口扛不扛得住，比上线之后被客户发现强。
聊接口排查时，客户最常提的几个问题
超时时间设多长合适
看业务。对外的接口一般几秒，内部调用可以短一些，别设得太长把问题拖住。
要不要加重试
可以，但只对安全的操作加。重试做不好，反而会把对端压垮。
怎么提前发现问题
给关键接口加耗时监控，超过阈值就报警，不用等客户反馈才知道。
常斌带团队，先讲这一句：先分层定位，再改代码，不靠猜。
先分层，再动手
我的建议是遇到超时先按顺序分三层定位，别急着改代码。定位准了，改起来才快。
160 多家深度合作的客户里，不少合作了五年以上。接口开发这块，信服无限会先给关键接口加上耗时日志。搭系统之前，告诉我出问题的是哪个接口、大概什么表现。