今天的行情相信大家都感受到了，而面试也是越来越卷了，从技术八股卷到业务场景。今天呢，给大家带来了6个关于第三方接口调用相关的坑。问题点不难，但是面试中突然问到可能回答起来会有点懵，虽然都知道，但是不一定能回答好。

接下来呢，我会带领大家整体的过一遍，大家刷到了就留个印象，后边的笔记呢，我也准备好了，评论区扣1然后私信我领取哈。大家也可以来吐槽吐槽自己遇到的一些坑，让更多的小伙伴看到，一起交流。

闲话少说，接下来我们就进入正题。

域名访问不到

首先第一个问题，域名访问不通，一般我们在第一次对接第三方平台的API接口时，可能会先通过浏览器或者postman调用一下。

对于这个点分两个方面看，要么是我有问题，要么是对方有问题。

• 自己的网络问题
• 对方域名访问不通
• 对方DNS解析有问题
• 对方服务未部署等等
• 对方设置了访问白名单

有可能你调用第三方平台的API接口时，他们的接口真的挂了，他们还不知道。还有一种最重要的情况，就是你的工作网络，是否可以访问这个外网的接口。

有些公司为了安全考虑，对内网的开发环境，是设置了防火墙的，或者有一些其他的限制，有些ip白名单，只能访问一些指定的外网接口。

如果你发现你访问的域名，在开发环境访问不通，就要到运维同学给你添加ip白名单了。

接口突然没返回数据

如果你调用第三方平台的某个API接口查询数据，刚开始一直都有数据返回。但突然某一天没返回数据了。但是该API接口能够正常响应。不要感到意外，有可能是第三方平台将数据删除了。

我对接完第三方平台的API接口后，部署到了测试环境，发现他们接口竟然没有返回数据，原因是他们有一天将测试环境的数据删完了。因此，在部署测试环境之前，要先跟对方沟通，要用哪些数据测试，不能删除。

还有一点，在我们自己程序中，我们永远不要相信三方平台的数据，如果出错了，我们要写容错策略。不能因为三方的错误，把自己系统给拖死。

token失效

有些平台的API接口在请求之前，先要调用另外一个API接口获取token，然后再header中携带该token信息才能访问其他的业务API接口。其实大多数我们自己的系统也是这么设计的。

在获取token的API接口中，我们需要传入账号、密码和密钥等信息。每个接口对接方，这些信息都不一样。

我们在请求其他的API接口之前，每次都实时调用一次获取token的接口获取token？还是请求一次token，将其缓存到redis中，后面直接从redis获取数据呢？

很显然我们更倾向于后者，因为如果每次请求其他的API接口之前，都实时调用一次获取token的接口获取token，这样每次都会请求两次接口，性能上会有一些影响。

如果将请求的token，保存到redis，又会出现另外一个问题：token失效的问题。

我们调用第三方平台获取token的接口获取到的token，一般都有个有效期，比如：1天，1个月等。

在有效期内，该API接口能够正常访问。如果超过了token的有效期，则该API接口不允许访问。

好办，我们把redis的失效时间设置成跟token的有效期一样不就OK了？

想法是不错，但是有问题。

你咋保证，你们系统的服务器时间，跟第三方平台的服务器时间一模一样？

我之前遇到过某大厂，提供了获取token接口，在30天内发起请求，每次都返回相同的token值。如果超过了30天，则返回一个新的。

有可能出现这种情况，你们系统的服务器时间要快一些，第三方平台的时间要慢一些。结果到了30天，你们系统调用第三方平台的获取token接口获取到了token还是老的token，更新到redis中了。

过一段时间，token失效了，你们系统还是用老的token访问第三方平台的其他API接口，一直都返回失败。但获取新的token却要等30天，这个时间太漫长了。

对于具体的错误码要设计重试机制：

为了解决这个问题，需要捕获token失效的异常。如果在调用其他的API接口是发现token失效了，马上请求一次获取token接口，将新的token立刻更新到redis中。

这样基本可以解决token失效问题，也能尽可能保证访问其他接口的稳定性和性能。

接口超时

系统上线之后，调用第三方API接口，最容易出现的问题，应该是接口超时问题了。系统到外部系统之间，有一条很复杂的链路，中间有很多环节出现问题，都可能影响API接口的相应时间。

这点很尴尬，别人的系统，咱们控制不了，你说让别人优化系统，人家立项调整上线估计就半个月，这还是情况好的，拖个半年的都有。别人体验的是你的系统，速度慢一点还能说得过去，要是老是超时失败反馈到用户层面。用户第一个找的就是你。。。。

作为API接口的调用方，面对第三方API接口超时问题，除了给他们反馈问题，优化接口性能之外。

我们更有效的方式，可能是增加接口调用的失败重试机制。

例如：

• 如果接口调用失败，则程序会立刻自动重试3次。
• 如果重试之后成功了，则该API接口调用成功。
• 如果重试3次之后还是失败，则该API接口调用失败。

偷偷改参数了

我之前调用过某平台的API接口获取指标的状态，之前根据双方约定的状态有：正常和禁用 两种。

然后将状态更新到我们的指标表中。后来，双方系统上线运行了好几个月。突然有一天，用户反馈说某一条数据明明删除了，为什么在页面上还是可以查到。此时，我查我们这边的指标表，发现状态是正常的。

然后查看调用该平台的API接口日志，发现返回的该指标的状态是：下架。

什么鬼，心里已经问候了八百遍了。。。

跟该平台的开发人员沟通后，发现他们改了状态的枚举，增加了：上架、下架等多个值，而且没有通知我们。这就坑了。我们这边的代码中判断，如果状态非禁用状态，都认为是正常状态。

而下架状态，自动被判断为正常状态。经过跟对方沟通后，他们确认下架状态，是非正常状态，不应该显示指标。他们改了数据，临时解决了该指标的问题。后来，他们按接口文档又改回了之前的状态枚举值。

这里还有一种其他的方案，把枚举信息也通过一个接口返回，然后做展示，这样就能避免前面提到的问题了。

接口时好时坏

不知道你在调用第三方接口时，有没有遇到过接口时好时坏的情况。5分钟前，该接口还能正常返回数据。

5分钟后，该接口返回503不可用。又过了几分钟，该接口又能正常返回数据了。

可能情况：

• 这种情况大概率是第三方平台在重启服务，在重启的过程中，可能会出现服务暂时不可用的情况。
• 第三方接口部署了多个服务节点，有一部分服务节点挂了。也会导致请求第三方接口时，返回值时好时坏的情况。
• 网关的配置没有及时更新，没有把已经下线的服务剔除掉。这样用户请求经过网关时，网关转发到了已经下线的服务，导致服务不可用。网关转发请求到正常的服务，该服务能够正常返回。

如果遇到该问题，要尽快将问题反馈给第三方平台，然后增加接口失败重试机制。