這真是一個巨大的坑，為了避免以後踩到同樣的坑和幫助剛接觸這塊的同學快速脫坑，我花了些時間研究問題的來龍去脈，提供了一個不太完美的解決方案，以及未來規劃的完美解決方案。

問題現象

在開發微信jssdk的影象介面功能時，測試環境和迴歸環境都ok。但是更新到預釋出環境後，功能就異常了，一直報圖片下載失敗。最後快到釋出時間時，功能又恢復正常了。於是按照常規流程進行了釋出。過了兩天，收到線上反饋的問題：使用者剛開始還能正常傳圖，用著用著就突然報錯說傳圖失敗，然後就一直不能用了。我們在測試環境模擬測試，功能又是正常的:(

查詢原因

這種偶現的問題一般都很難迅速定位到具體原因，而且本地和測試環境正常，預釋出環境和線上異常，但是又不能進行除錯。於是只能根據程式碼邏輯進行猜測性判斷和嘗試修復，中間走了大量的彎路，最後發現，刪除儲存access_token的redis值，再使用時功能正常。

技術分析

問題暫時解決了，但這不是長久之計。於是我花了點時間閱讀官方文件，發現這果真是個大坑啊！官方文件原文如下：

第一個紅色框裡的內容，我測試了三次，第一次連續請求13遍，access_token發生了變化；第二次連續請求12遍，access_token發生了變化；第三次連續請求19遍，access_token發生了變化。（坑一）

第二個紅色框裡的內容，我們有開發環境，測試環境，迴歸環境，預釋出環境，正式環境，都是同一套程式碼，同一個微訊號，相當於每個環境都是單獨的中控伺服器。（坑二）

現場還原

搞清楚問題後，我們通過一些手段嘗試性的觸發問題現象：

1、測試環境下，清空access_token的redis資料。

2、正常測試，功能ok，檢視access_token的redis內容，這裡假設值為A。

3、手動呼叫介面重新整理access_token，大概十幾次後，值變化為B。

4、再次正常測試，發現功能異常（因為此時儲存在redis的access_token已經過期）。

5、清空access_token的redis資料，再次測試，功能又恢復正常。

現在問題終於變成必現的了:)

解決方案

現在我們搞清楚問題的原因是儲存在redis的access_token可能在很短的時間內過期（因為有太多中控伺服器啦），但是我們一般設定的有效期都接近或等於7200s，這就導致一旦出現問題的話，如果不清理redis，問題就會持續2小時左右，這簡直就是災難！

目前想到的比較理想的解決方案就是：伺服器發現功能異常時，重新整理access_token並更新redis，然後再次呼叫介面。這種容錯機制本來是微信的事-_-！

未來規劃

正如開頭所說，這的確是個巨坑，未來只能期望微信獲取access_token的介面能夠完善：

1、說好的2小時過期時間，就得保證2小時內不過期

2、返回的過期時間欄位為還剩多少秒過期，而不是每次都返回7200s

然而微信並沒有