為了項目性能等方面的考慮，有時候有必要為用戶經(jīng)常訪問的頁面使用緩存機制；在技術(shù)上，服務端和前端都有相應的緩存機制。比如傳統(tǒng)的session及cookie等等，在微信小程序中，并沒有cookie機制，但有本地緩存。小程序官方文檔對本地緩存的介紹如下：

每個微信小程序都可以有自己的本地緩存，可以通過 wx.setStorage（wx.setStorageSync）、wx.getStorage（wx.getStorageSync）、wx.clearStorage（wx.clearStorageSync）可以對本地緩存進行設置、獲取和清理。同一個微信用戶，同一個小程序 storage 上限為 10MB。localStorage 以用戶維度隔離，同一臺設備上，A 用戶無法讀取到 B 用戶的數(shù)據(jù)。其中?localStorage 是持久存儲的，但是我們不建議將關鍵信息全部存在 localStorage，以防用戶換設備的情況。

上面一句翻譯成簡潔的人話就是：本地緩存localStorage存在于客戶端中，不同用戶所對應的緩存數(shù)據(jù)是相互獨立并且因設備而隔離的，而且是持久存儲（除非用戶清空該小程序的數(shù)據(jù)）。

在項目開發(fā)過程中，我們利用緩存機制的時候，一般的都需要設置一個過期時間，而不管是session還是cookie我們除了可以設置、獲取和清理緩存外，我們可以在設置緩存的同時設置一個“過期時間”。而從以上小程序關于數(shù)據(jù)緩存API的介紹中，我們并沒有看到關于數(shù)據(jù)緩存過期時間設置的API。

那么這樣似乎對于很多需要使用到緩存機制的場景留下遺憾，以我們微構(gòu)網(wǎng)絡官方小程序為例，首頁的幾乎所有的數(shù)據(jù)全部是通過服務端API提供的數(shù)據(jù)，如果每次刷新小程序頁面都需要重新通過wx.request這個接口拉取數(shù)據(jù)，那么花在網(wǎng)絡請求的時間至少是100ms以上，這不僅不利于用戶體驗也浪費了計算資源。而如果，直接按照文檔中的表面化的應用數(shù)據(jù)緩存API，那么數(shù)據(jù)會持久化存儲，那么首頁中包括案例以及其他動態(tài)更新的數(shù)據(jù)怎么更新？

那么是不是就必須留下這樣的遺憾呢？如果果然會留下這樣的遺憾，那么我相信騰訊肯定會解決這樣的問題的。其實我們可以參考諸如cookie這樣的緩存機制，我們自己“造”一個過期時間。在設置某緩存數(shù)據(jù)A的時候，我們可以同時設置一個過期時間值的數(shù)據(jù)緩存B；在下一次打開該頁面的時候，不僅需要判斷數(shù)據(jù)A是否存在，也需要比較B與當前時間，如果符合要求則使用本地緩存的數(shù)據(jù)A，否則則重新拉取數(shù)據(jù)并刷新A和B。以上邏輯翻譯成代碼則為如下，首先是拉取服務端數(shù)據(jù)成功后同時設置兩個數(shù)據(jù)緩存，

以上的index_data是我們需要設置的緩存數(shù)據(jù)，而index_data_expiration則是與之對應的時間數(shù)據(jù)，其中3000000則是3000s，當用戶進入該頁面時，進行緩存數(shù)據(jù)判斷：

在項目實踐過程中，我們可以根據(jù)以上邏輯把這種方法封裝起來；此外，緩存的過期時間，我們也可以讀取服務端設置的超時時間，這樣小程序發(fā)布后我們可以在服務端靈活變更調(diào)節(jié)具體的數(shù)值了。如果你有程序小程序開發(fā)制作需求，可以聯(lián)系我們喲，微構(gòu)網(wǎng)絡專業(yè)提供微信小程序開發(fā)服務。