一、引言：緩存不是配置項，而是架構(gòu)決策

在CSDN和社區(qū)中，關(guān)于Nginx緩存的文章數(shù)以千計，但絕大多數(shù)停留在“怎么配”的層面：expires 7d、add_header Cache-Control、etag on……這些指令本身沒有錯，但如果你不理解背后的原則，就會陷入兩個極端：

• 緩存濫用：一刀切設(shè)置長過期時間，發(fā)版后用戶看不到更新，客服被“清緩存”投訴淹沒；
• 緩存恐懼：因為怕出問題干脆不配緩存，每次請求都全量傳輸，帶寬成本飆升，首屏?xí)r間居高不下。

這兩種問題的根源相同：把緩存當(dāng)成了孤立的配置項，而非與資源語義、構(gòu)建體系、協(xié)議規(guī)范深度綁定的架構(gòu)決策。

瀏覽器緩存的本質(zhì)，是用HTTP協(xié)議將“資源變更語義”精確傳遞給客戶端。做對了，它是性能優(yōu)化的終極武器；做錯了，它是數(shù)據(jù)一致性的定時炸彈。本文不講零散的配置技巧，而是提煉出六條經(jīng)過大規(guī)模生產(chǎn)驗證的緩存原則。掌握這些原則，你就能在任何項目中自主設(shè)計出正確的緩存策略，而不是照搬模板卻不知其所以然。

二、原則一：緩存策略必須與資源變更語義對齊

這是所有緩存原則的基石。不存在“萬能緩存配置”，只存在“與資源語義匹配的緩存配置”。

2.1 資源分類模型

2.2 核心推論

• 只有URL本身就是內(nèi)容指紋的資源，才配享有永久緩存。文件名中的content hash是安全前提，脫離了它談永久緩存就是埋雷。
• HTML是緩存體系的錨點。它引用了帶hash的資源，自身卻不能被強制緩存。HTML的更新即時性決定了整個緩存鏈條能否正確運轉(zhuǎn)。
• API和私有數(shù)據(jù)的默認立場應(yīng)該是“不緩存”。除非有明確的業(yè)務(wù)需求和驗證機制，否則 no-store 是最安全的起點。

?? 自檢清單：為你的每一種資源類型回答三個問題：它多久變一次？變化時URL會不會變？如果緩存了舊版本，后果有多嚴重？答案決定了你的緩存策略。

三、原則二：強制緩存與協(xié)商緩存是協(xié)同關(guān)系，不是替代關(guān)系

很多開發(fā)者將二者對立起來，要么只用強制緩存，要么只用協(xié)商緩存。正確的認知是：它們是一個兩層決策流程中的不同階段，各自承擔(dān)不可替代的職責(zé)。

3.1 兩層防御模型

請求發(fā)起
    │
    ▼
┌─────────────────────────────┐
│ 第一層：強制緩存             │ ← 解決“不變”的效率
│ max-age內(nèi)：零網(wǎng)絡(luò)請求        │
└──────────────┬──────────────┘
               │ 過期 / no-cache
               ▼
┌─────────────────────────────┐
│ 第二層：協(xié)商緩存             │ ← 解決“變”的安全
│ ETag/LM驗證：304輕量往返     │
└─────────────────────────────┘

3.2 為什么不能只用其中一層？

3.3 最佳組合范式

• 帶Hash資源：max-age=1y, immutable（強制緩存封頂，immutable消除刷新驗證）
• HTML/SW：no-cache（禁止強制緩存，但允許304復(fù)用本地副本）
• API：no-store（禁止一切緩存）或 max-age=60, must-revalidate（極短窗口+嚴格驗證）

?? 記住：強制緩存是性能天花板，協(xié)商緩存是安全底線。生產(chǎn)環(huán)境中，每一類資源都應(yīng)該在這兩層中找到自己的精確位置。

四、原則三：永遠不要發(fā)出“裸奔”的響應(yīng)頭

所謂“裸奔”，是指響應(yīng)既沒有 Cache-Control，也沒有 Expires，只有 Last-Modified。這種狀態(tài)會觸發(fā)HTTP協(xié)議的啟發(fā)式緩存（Heuristic Caching），這是生產(chǎn)環(huán)境中最危險的隱形行為。

4.1 啟發(fā)式緩存的觸發(fā)條件

根據(jù)RFC 7234，當(dāng)響應(yīng)滿足以下條件時，瀏覽器和中間代理可以自動計算隱式過期時間：

1. 狀態(tài)碼為可緩存狀態(tài)（200、301、404等）
2. 無 Cache-Control 且無 Expires
3. 有 Last-Modified

隱式max-age = (當(dāng)前時間 - Last-Modified) × 10%

一個10天前修改的文件會被自動緩存1天，而你對此毫無察覺、無法控制。

4.2 防御措施

在Nginx中設(shè)置全局兜底策略，確保每個響應(yīng)都有明確的緩存聲明：

server {
    # 兜底：對所有未顯式設(shè)置緩存頭的響應(yīng)，強制協(xié)商緩存
    add_header Cache-Control "no-cache" always;
    
    # 各location中按需覆蓋為更具體的策略
    location /assets/ { ... }
    location /api/ { ... }
}

?? always 參數(shù)至關(guān)重要。不加 always 時，add_header 僅在2xx/3xx響應(yīng)中生效，4xx/5xx錯誤響應(yīng)仍可能裸奔并被意外緩存。

4.3 核心原則

在生產(chǎn)環(huán)境中，不存在“默認緩存行為是安全的”這一假設(shè)。每一層緩存行為都應(yīng)該是顯式設(shè)計的結(jié)果，而非協(xié)議默認值的副產(chǎn)品。

五、原則四：Vary頭是緩存正確性的守門員

Vary頭告訴緩存層（瀏覽器、CDN、代理）：“這個資源的緩存鍵不僅包含URL，還包含指定的請求頭”。忽略Vary是CDN亂碼、多語言錯位、壓縮版本混淆等問題的頭號元兇。

5.1 必須設(shè)置Vary的場景

5.2 Nginx配置要點

# 開啟壓縮時必須手動添加Vary（Nginx不會自動加?。?
gzip on;
add_header Vary "Accept-Encoding";

# 多值Vary的正確寫法
add_header Vary "Accept-Encoding, Accept-Language";

5.3 常見誤區(qū)

• 誤區(qū)1：“我開了gzip，Nginx會自動處理Vary” → ? Nginx不會自動添加Vary頭
• 誤區(qū)2：“Vary越多越安全” → ? 過多Vary值會導(dǎo)致緩存碎片化，命中率驟降。只聲明真正影響響應(yīng)內(nèi)容的請求頭
• 誤區(qū)3：“Vary: * 最安全” → ? 這等價于禁止緩存，完全喪失緩存收益

?? 原則：Vary的值應(yīng)該精確反映“哪些請求頭會導(dǎo)致同一URL返回不同內(nèi)容”。不多不少，恰到好處。

六、原則五：緩存配置必須與構(gòu)建體系綁定

緩存策略不能脫離前端工程化獨立存在。Nginx配置和構(gòu)建工具是同一個緩存體系的兩個端面，任何一端脫節(jié)都會導(dǎo)致體系崩塌。

6.1 Content Hash是強制緩存的工程前提

現(xiàn)代構(gòu)建工具（Vite/Webpack/Rspack）默認對JS/CSS輸出帶content hash的文件名。Nginx只需匹配哈希模式即可安全設(shè)置永久緩存：

# 匹配8位及以上十六進制哈希
location ~* \.[a-f0-9]{8,}\.(js|css)$ {
    expires 1y;
    add_header Cache-Control "public, max-age=31536000, immutable";
}

?? 確認你的構(gòu)建配置確實開啟了content hash。如果文件名不含哈希，永久緩存會導(dǎo)致發(fā)版后用戶無法獲取新代碼。

6.2 HTML是緩存體系的錨點

HTML文件引用了帶哈希的JS/CSS，自身卻不能被強制緩存：

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

工作原理鏈：用戶訪問→驗證HTML（304/200）→新版HTML引用新hash資源→瀏覽器下載新資源（永久緩存）→舊資源自然淘汰。

6.3 Service Worker的特殊契約

sw.js 本身絕對不能被強制緩存，否則瀏覽器無法發(fā)現(xiàn)新版本SW：

location = /sw.js {
    add_header Cache-Control "no-cache, must-revalidate";
}

SW內(nèi)部通過Cache API管理的資源緩存與HTTP緩存頭無關(guān)，但SW文件自身的更新必須依賴協(xié)商緩存。

6.4 部署流程必須保留文件mtime

Nginx默認ETag基于 文件大小+mtime 生成。如果部署工具重置了mtime（如scp、某些Docker COPY），ETag將在每次部署后變化，304命中率驟降。

解決方案：使用 rsync -t、tar --preserve 或在CI/CD中顯式保留原始mtime。

?? 核心認知：緩存策略不是運維單方面的事，它是前端工程化、構(gòu)建體系、部署流程、Nginx配置四方協(xié)同的產(chǎn)物。任何一方掉鏈子，緩存體系就會失效。

七、原則六：緩存必須是可觀測、可驗證、可回滾的

生產(chǎn)環(huán)境的緩存策略不能“配完就忘”。它需要持續(xù)的觀測和驗證機制。

7.1 可觀測：日志與監(jiān)控

# 自定義日志格式，記錄緩存狀態(tài)
log_format cache_log '$remote_addr $status $upstream_cache_status $request_uri';

# 對純靜態(tài)資源關(guān)閉訪問日志（減少IO）
location ~* \.[a-f0-9]{8,}\.(js|css|png)$ {
    access_log off;
}

關(guān)鍵指標(biāo)：

• 304占比：HTML/SW應(yīng)在60%~90%，過低說明驗證器不穩(wěn)定
• 強制緩存命中率：通過CDN日志或瀏覽器DevTools統(tǒng)計
• 帶寬節(jié)省率：對比開啟緩存前后的出口流量

7.2 可驗證：自動化檢測

# CI/CD中加入緩存頭檢查腳本
curl -sI https://example.com/app.a1b2c3.js | grep -q "immutable" || exit 1
curl -sI https://example.com/index.html | grep -q "no-cache" || exit 1

7.3 可回滾：緩存失效預(yù)案

當(dāng)緩存策略出錯時，必須有快速止血手段：

• 緊急發(fā)版：修改HTML中的資源引用hash，舊緩存自然失效
• 全局降級：Nginx配置中將所有 max-age 改為0，臨時退化為協(xié)商緩存
• CDN purge：通過API批量清除錯誤緩存

?? 原則：沒有觀測的緩存是盲飛，沒有回滾預(yù)案的緩存是賭博。生產(chǎn)環(huán)境的每一層緩存都應(yīng)該有對應(yīng)的監(jiān)控指標(biāo)和應(yīng)急方案。

八、六大原則速查表

九、結(jié)語

到此這篇關(guān)于深入解析Nginx瀏覽器緩存原則的文章就介紹到這了,更多相關(guān)nginx瀏覽器緩存內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論