從“甩鍋”到“兜底”，一套代碼實現(xiàn)緩存自愈，把用戶體驗拉回 100 分

一、為什么“清緩存”成了技術圈的梗

“老師，頁面白屏了！”

“清下瀏覽器緩存試試。”

—— 這段對話每天都在各家公司重復上演。

用戶不會理解「緩存」是什么，他們只會覺得“你們網(wǎng)站又出 Bug 了”。

更尷尬的是，90% 的線上“舊代碼”問題，確實只靠強制刷新就能解決。

于是前端背鍋，用戶流失，產(chǎn)品經(jīng)理發(fā)飆。

根源

• 靜態(tài)資源走「強緩存」（Cache-Control/Expires），服務器都收不到請求。
• index.html 本身也被緩存，導致 chunk-vite-abc123.js 404 卻沒人知道。
• 發(fā)版窗口沒做「灰度 + 版本兜底」，一掛全掛。

目標

讓用戶永遠不再看到舊代碼，同時永遠不再聽到“清緩存”三個字。

二、先給緩存“把個脈”：瀏覽器到底緩存了誰？

結論

只有 Service Worker 能讓前端“自己管自己”，其余都無法在出錯時主動清理。

因此「讓用戶清緩存」本質是把不可控因素甩給用戶——極不專業(yè)。

三、設計思路：把“發(fā)版”做成“自愈”

版本號 → 可對比，每次 CI 在全局注入 __APP_VERSION__ = '1.2.3-beta.1+202509211100'

服務器 → 永遠返回最新 index.html（Cache-Control: no-cache）

前端 → 輪詢版本號，發(fā)現(xiàn)不一致即主動 reload并跳過緩存

兜底 → 若 JS 拋錯 404，同樣觸發(fā) reload

灰度 → 只有帶 ?v=latest 的 5% 流量走新版本，出錯自動回滾

四、代碼落地（Vue3 + Vite 為例，React/Angular 同理）

1. CI 注入版本

# .github/workflows/release.yml
echo "export const APP_VERSION = '${GITHUB_REF_NAME}+$(date +%Y%m%d%H%M)';" > src/meta/version.js

vite.config.ts

import { defineConfig } from 'vite'
import { APP_VERSION } from './src/meta/version'
export default defineConfig({
  define: {
    __APP_VERSION__: JSON.stringify(APP_VERSION),
  },
})

2. 版本輪詢模塊（src/core/version-guard.ts）

const VERSION_CHECK_INTERVAL = 60_000 // 1min
const RETRY_MAX = 3

async function fetchMeta() {
  // 加 search 防止自身被緩存
  const res = await fetch('/meta.json?t=' + Date.now())
  return res.json() as Promise<{ version: string }>
}

export function startVersionGuard() {
  let retry = 0
  const loop = async () => {
    try {
      const { version } = await fetchMeta()
      if (version !== __APP_VERSION__) {
        // 發(fā)現(xiàn)新版本
        const event = new CustomEvent('sw-update', { detail: { version } })
        window.dispatchEvent(event)
        // 立即刷新，skipWaiting 效果
        location.reload()
      } else {
        retry = 0
      }
    } catch (e) {
      if (++retry >= RETRY_MAX && import.meta.env.PROD) {
        // 可能 index.html 都是舊的，強制硬刷新
        location.href = location.href + '?v=' + Date.now()
      }
    }
  }
  setInterval(loop, VERSION_CHECK_INTERVAL)
  loop() // 立即執(zhí)行一次
}

3. 404 兜底（src/core/error-tracker.ts）

window.addEventListener('error', (e) => {
  const src = e.filename ?? ''
  if (/chunk-.*\.js$/.test(src) && e.message.includes('Failed to fetch')) {
    // 舊 chunk 404
    sessionStorage.setItem('force-reflow', '1')
    location.href = location.href + '?v=' + Date.now()
  }
})

4. index.html 永不緩存

location = /index.html {
  add_header Cache-Control "no-cache, no-store, must-revalidate";
}

5. 資源文件長期緩存 + 內容哈希

// vite 默認 chunk-[hash].js，確保文件名一變就 404，觸發(fā)兜底
build.rollupOptions.output.entryFileNames = 'static/js/[name]-[hash].js'

五、灰度 & 回滾：把“爆炸半徑”縮到最小

1.邊緣層（CDN/Nginx）按 Cookie 或 Query 分流

if ($arg_v = latest) { proxy_pass http://new-bucket; }

2.前端報錯統(tǒng)一上報 Sentry，1 分鐘錯誤率 > 0.2% 自動回滾（CI 調用 CDN 回源接口切流）

3.用戶側：版本不一致時先彈柔性提示“檢測到新版本，3 秒后自動刷新”，避免突兀。

六、最終效果

發(fā)版后 60s 內，所有在線用戶靜默切換到最新代碼。

用戶本地緩存的 chunk-abc123.js 404 → 自動硬刷新，零人工介入。

客服再也沒收到“頁面空白”的工單。

產(chǎn)品經(jīng)理主動在群里點贊：“最近怎么沒人報 bug 了？”

七、常見疑問 Q&A

Q1. 輪詢不會增加服務器壓力嗎？

/meta.json 只有 200B，1 分鐘一次，1 萬日活一天才 1k×60×24 ≈ 1.4M 請求，靜態(tài)文件 CDN 0.01 元/萬次，成本忽略不計。

Q2. 移動端后臺標簽長時間不刷新怎么辦？

監(jiān)聽 visibilitychange，切回前臺立即檢查版本；再配合 Service Worker 的 clients.claim() 可瞬間激活新代碼。

Q3. 企業(yè)內網(wǎng)無法聯(lián)網(wǎng)，怎么更新？

內網(wǎng)場景建議把 index.html 做成 no-cache，發(fā)版通知用戶刷新當前頁即可；其余資源仍走哈希緩存，平衡速度與可靠性。

八、結語：把“清緩存”寫進歷史

“清緩存”本質是把技術債轉嫁給用戶。

只要做到：

• 版本可感知
• 入口文件無緩存
• 舊資源 404 能兜底
• 灰度可回滾

到此這篇關于前端緩存策略的自解方案全解析的文章就介紹到這了,更多相關前端緩存策略內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論