今天的行情相信大家都感受到了，而面試也是越來越卷了，從技術八股卷到業務場景。今天呢，給大家帶來了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不可用。又過了幾分鐘，該接口又能正常返回數據了。

可能情況：

• 這種情況大概率是第三方平臺在重啟服務，在重啟的過程中，可能會出現服務暫時不可用的情況。
• 第三方接口部署了多個服務節點，有一部分服務節點掛了。也會導致請求第三方接口時，返回值時好時壞的情況。
• 網關的配置沒有及時更新，沒有把已經下線的服務剔除掉。這樣用戶請求經過網關時，網關轉發到了已經下線的服務，導致服務不可用。網關轉發請求到正常的服務，該服務能夠正常返回。

如果遇到該問題，要盡快將問題反饋給第三方平臺，然后增加接口失敗重試機制。