Bootstrap Table 服務端分頁優化：避免重複請求已加載數據

問題場景

使用 Bootstrap Table 的服務端分頁模式時，每次翻頁都會向後端發起請求。若用戶頻繁切換頁碼，會造成不必要的服務器壓力與帶寬浪費。開發者希望：已加載過的頁面數據在本地緩存，再次訪問時直接讀取緩存，不再請求服務端。

解決思路

方案一：客戶端全量緩存（適合數據量較小）

首次加載時一次性請求所有數據存入本地變量或 localStorage，之後分頁完全在前端處理。Bootstrap Table 支持 data 參數直接渲染本地數組，配合 pagination: true 即可實現純前端分頁，零服務端交互。

方案二：分頁級緩存策略（適合數據量大）

1. 維護一個 Map<pageNumber, data> 緩存對象。
2. 請求前判斷緩存中是否存在該頁數據，存在則直接渲染；不存在則發起 AJAX 請求並寫入緩存。
3. 可結合 sessionStorage 持久化緩存，頁面刷新不丟失。

var pageCache = {};
$('#table').bootstrapTable({
    url: '/api/data',
    pagination: true,
    sidePagination: 'server',
    onLoadSuccess: function(data) {
        pageCache[this.options.pageNumber] = data.rows;
    },
    // 重寫查詢參數攔截請求
    queryParams: function(params) {
        if (pageCache[params.pageNumber]) {
            // 手動渲染緩存數據並返回 false 取消請求
            $('#table').bootstrapTable('load', pageCache[params.pageNumber]);
            return false;
        }
        return params;
    }
});

方案三：HTML5 離線存儲（進階）

利用 Service Worker 或 Application Cache（已棄用）實現靜態資源與數據離線訪問，但配置較複雜，通常不作為首選。

最佳實踐建議

• 數據量 < 1 萬條：推薦方案一，代碼最簡單，體驗最流暢。
• 數據量較大：採用方案二，平衡性能與內存佔用。
• 注意緩存失效機制：數據更新後需清空對應緩存，避免髒讀。