一、引言：為什么強(qiáng)制緩存是Web性能的“第一優(yōu)先級(jí)”？

在所有Web性能優(yōu)化手段中，瀏覽器強(qiáng)制緩存是唯一能將網(wǎng)絡(luò)請(qǐng)求徹底歸零的機(jī)制。當(dāng)資源命中強(qiáng)制緩存時(shí)，瀏覽器直接從本地磁盤(pán)或內(nèi)存讀取，不發(fā)起DNS解析、TCP握手、TLS協(xié)商，甚至不會(huì)向Nginx發(fā)送任何HTTP請(qǐng)求。這意味著：

• 用戶感知加載時(shí)間為零；
• 服務(wù)器帶寬和CPU消耗為零；
• CDN回源壓力為零。

然而在實(shí)際項(xiàng)目中，強(qiáng)制緩存的配置往往走向兩個(gè)極端：要么完全不配，每次刷新都全量下載；要么一刀切設(shè)置 expires 7d，導(dǎo)致發(fā)版后用戶看不到更新，只能引導(dǎo)用戶“清除瀏覽器緩存”。這兩種做法的根源都是同一個(gè)：沒(méi)有理解強(qiáng)制緩存的生效條件，也沒(méi)有將緩存策略與前端工程化的內(nèi)容哈希體系對(duì)齊。

本文將從HTTP協(xié)議原理出發(fā)，結(jié)合Nginx配置與現(xiàn)代前端構(gòu)建工具，幫你建立一套“該永久緩存的絕不驗(yàn)證、該更新的立即生效”的精準(zhǔn)強(qiáng)制緩存體系。

二、核心原理：強(qiáng)制緩存的觸發(fā)條件與決策流程

2.1 什么是強(qiáng)制緩存？

強(qiáng)制緩存（Strong Caching）是指瀏覽器在收到帶有明確有效期標(biāo)識(shí)的響應(yīng)后，在有效期內(nèi)完全跳過(guò)網(wǎng)絡(luò)請(qǐng)求，直接使用本地副本的機(jī)制。它與協(xié)商緩存（304驗(yàn)證）的本質(zhì)區(qū)別在于：強(qiáng)制緩存連條件請(qǐng)求都不發(fā)。

2.2 觸發(fā)條件

瀏覽器進(jìn)入強(qiáng)制緩存路徑需要同時(shí)滿足以下條件：

1. 響應(yīng)包含有效的 Cache-Control: max-age=N 或 Expires 頭；
2. 當(dāng)前時(shí)間距響應(yīng)生成時(shí)間未超過(guò)max-age（或未超過(guò)Expires指定的絕對(duì)時(shí)間）；
3. 用戶未執(zhí)行強(qiáng)制刷新（Ctrl+F5 / Cmd+Shift+R）；
4. 響應(yīng)未被標(biāo)記為 no-store。

2.3 決策流程圖

瀏覽器發(fā)起資源請(qǐng)求
        │
        ▼
┌───────────────────────────┐
│ 檢查 Cache-Control       │
│ max-age 是否過(guò)期？        │
└────────────┬──────────────┘
      未過(guò)期  │         已過(guò)期/無(wú)指令
             ▼                  ▼
    ┌────────────────┐   進(jìn)入?yún)f(xié)商緩存流程
    │ 是否有immutable？│   (If-None-Match / 
    └───────┬────────┘    If-Modified-Since)
     有     │      無(wú)
            ▼          ▼
    直接使用本地副本   普通強(qiáng)制緩存
    (刷新也不驗(yàn)證)    (刷新時(shí)可能重新驗(yàn)證)

?? 關(guān)鍵認(rèn)知：immutable 是強(qiáng)制緩存的“終極形態(tài)”。沒(méi)有它時(shí)，Chrome等瀏覽器在用戶主動(dòng)點(diǎn)擊刷新按鈕時(shí)會(huì)忽略max-age并發(fā)起條件請(qǐng)求；有了它，即使用戶刷新也不會(huì)驗(yàn)證。對(duì)于帶內(nèi)容哈希的資源，immutable 能額外消除10%~20%的304請(qǐng)求。

2.4 max-age vs Expires

?? 生產(chǎn)環(huán)境必須同時(shí)設(shè)置兩者。max-age 是現(xiàn)代瀏覽器的判斷依據(jù)，Expires 是HTTP/1.0客戶端和部分老舊CDN的兜底字段。只設(shè)其中一個(gè)都會(huì)在特定場(chǎng)景下失效。

三、Nginx強(qiáng)制緩存配置實(shí)戰(zhàn)

3.1 按資源語(yǔ)義分級(jí)配置（生產(chǎn)模板）

server {
    listen 80;
    root /var/www/html;
    # ========== 帶內(nèi)容哈希的構(gòu)建產(chǎn)物：永久強(qiáng)制緩存 ==========
    # Vite/Webpack/Rspack輸出格式：app.a1b2c3d4.js, style.e5f6g7h8.css
    location ~* \.[a-f0-9]{8,}\.(js|css)$ {
        expires 1y;
        add_header Cache-Control "public, max-age=31536000, immutable";
        access_log off;
    }
    # 圖片/字體等二進(jìn)制資源（帶哈希）
    location ~* \.[a-f0-9]{8,}\.(png|jpg|jpeg|gif|svg|webp|avif|woff2?|ttf|eot)$ {
        expires 1y;
        add_header Cache-Control "public, max-age=31536000, immutable";
        access_log off;
    }
    # ========== HTML入口文件：禁止強(qiáng)制緩存 ==========
    # HTML是緩存體系的錨點(diǎn)，必須每次都驗(yàn)證
    location ~* \.html?$ {
        add_header Cache-Control "no-cache, must-revalidate";
        etag on;
        last_modified on;
    }
    # ========== 不帶哈希的靜態(tài)資源：中等強(qiáng)制緩存 ==========
    location ~* \.(ico|txt|pdf|mp4|webm|mp3)$ {
        expires 30d;
        add_header Cache-Control "public, max-age=2592000";
        etag on;  # 強(qiáng)制緩存過(guò)期后走協(xié)商緩存兜底
    }
    # ========== API/動(dòng)態(tài)接口：禁止一切緩存 ==========
    location /api/ {
        add_header Cache-Control "no-store";
        proxy_pass http://backend;
    }
}

3.2 六個(gè)關(guān)鍵配置細(xì)節(jié)深度解析

①immutable的價(jià)值被嚴(yán)重低估

immutable 指令告訴瀏覽器：“此URL對(duì)應(yīng)的內(nèi)容永遠(yuǎn)不會(huì)變更”。它的實(shí)際效果遠(yuǎn)超 max-age=1y：

• 普通強(qiáng)緩存：用戶點(diǎn)擊刷新按鈕時(shí)，Chrome會(huì)忽略max-age，發(fā)起 If-None-Match 條件請(qǐng)求（304往返）；
• immutable強(qiáng)緩存：即使用戶刷新，瀏覽器也完全不發(fā)請(qǐng)求，直接使用本地副本。

對(duì)于帶內(nèi)容哈希的資源，文件名本身就保證了內(nèi)容的唯一性，immutable 是語(yǔ)義上完全正確的聲明。不要省略它。

②add_header的繼承陷阱

這是Nginx新手最常踩的坑：add_header 不會(huì)繼承到子location。

# ? 錯(cuò)誤：/assets/下的Cache-Control會(huì)丟失
server {
    add_header Cache-Control "public, max-age=31536000";
    location /assets/ {
        add_header X-Custom "value";  # 上一行的Cache-Control在此處完全失效！
    }
}
# ? 正確：每個(gè)需要緩存頭的location都必須顯式設(shè)置
location /assets/ {
    add_header Cache-Control "public, max-age=31536000, immutable";
    add_header X-Custom "value";
}

如果你希望統(tǒng)一管理，可以使用 map + always 參數(shù)實(shí)現(xiàn)集中式緩存頭下發(fā)，避免遺漏。

③access_log off不是可選項(xiàng)

命中強(qiáng)制緩存的請(qǐng)求不到達(dá)服務(wù)器，但以下場(chǎng)景仍會(huì)產(chǎn)生日志：

• 首次訪問(wèn)（緩存未建立）；
• 強(qiáng)制緩存過(guò)期后的條件請(qǐng)求（304）；
• 新部署后舊緩存失效的首次請(qǐng)求。

對(duì)于高頻靜態(tài)資源，這些日志毫無(wú)分析價(jià)值卻消耗大量磁盤(pán)IO。對(duì)純靜態(tài)資源location關(guān)閉訪問(wèn)日志是生產(chǎn)環(huán)境的基本素養(yǎng)。

④ Content Hash是強(qiáng)制緩存的安全前提

永久強(qiáng)制緩存只有在文件名包含內(nèi)容哈希時(shí)才安全。如果文件名不含哈希而設(shè)置了長(zhǎng)max-age，發(fā)版后用戶將無(wú)法獲取新代碼，直到緩存自然過(guò)期。

確認(rèn)你的構(gòu)建工具開(kāi)啟了content hash：

// Vite
export default defineConfig({
  build: { rollupOptions: { output: { entryFileNames: '[name].[hash].js' } } }
})
// Webpack
output: { filename: '[name].[contenthash].js' }

?? 如果你的項(xiàng)目仍有不帶哈希的JS/CSS文件，絕對(duì)不能對(duì)其設(shè)置永久強(qiáng)制緩存。應(yīng)將其歸入“中等強(qiáng)制緩存+協(xié)商緩存兜底”類別。

⑤ Vary頭與壓縮的協(xié)同

開(kāi)啟gzip/brotli后，同一URL可能返回不同壓縮版本的響應(yīng)體。如果不添加 Vary: Accept-Encoding，CDN或中間代理可能將gzip版本緩存后返回給不支持壓縮的客戶端，導(dǎo)致亂碼：

gzip on;
add_header Vary "Accept-Encoding";  # ? 開(kāi)啟壓縮時(shí)必須手動(dòng)添加

Nginx不會(huì)自動(dòng)添加Vary頭，這是很多線上亂碼問(wèn)題的根源。

⑥ HTTPS下的public與private區(qū)分

# 公共資源（CDN可緩存）
add_header Cache-Control "public, max-age=31536000, immutable";
# 私有資源（僅瀏覽器緩存，CDN/代理不緩存）
add_header Cache-Control "private, max-age=3600";

HTTPS響應(yīng)默認(rèn)被瀏覽器視為可緩存，但CDN和共享代理對(duì) private 響應(yīng)不會(huì)存儲(chǔ)。涉及用戶個(gè)人數(shù)據(jù)的靜態(tài)資源（如頭像、個(gè)人配置JSON）必須使用 private。

四、與前端工程化的對(duì)齊策略

強(qiáng)制緩存配置不能脫離構(gòu)建體系獨(dú)立存在。以下是完整的對(duì)接清單：

4.1 HTML是緩存體系的錨點(diǎn)

整個(gè)強(qiáng)制緩存體系能夠安全運(yùn)轉(zhuǎn)的前提是：HTML文件本身不被強(qiáng)制緩存。

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

工作原理鏈：

1. 用戶訪問(wèn) → 瀏覽器驗(yàn)證index.html（304或200）；
2. 新版index.html引用 <script src="/app.a1b2c3.js">；
3. 瀏覽器發(fā)現(xiàn)本地?zé)o app.a1b2c3.js → 下載并永久緩存；
4. 舊版 app.x9y8z7.js 不再被引用，自然淘汰。

?? 如果HTML被強(qiáng)制緩存，整個(gè)鏈條在第1步就斷裂了。這是“發(fā)版后用戶看到舊頁(yè)面”最常見(jiàn)的原因。

4.2 Service Worker腳本的特殊處理

sw.js 本身絕對(duì)不能被強(qiáng)制緩存，否則瀏覽器無(wú)法發(fā)現(xiàn)新版本SW，導(dǎo)致應(yīng)用無(wú)法更新：

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

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

4.3 第三方資源的緩存策略

通過(guò)npm引入的庫(kù)（如React、Vue）通常由構(gòu)建工具打包進(jìn)帶哈希的bundle中，已自動(dòng)享受永久強(qiáng)制緩存。但如果通過(guò)CDN script標(biāo)簽直接引入：

<script src="https://cdn.example.com/react@18.2.0/umd/react.production.min.js"></script>

這類URL版本號(hào)鎖定在路徑中，等價(jià)于內(nèi)容哈希，可以安全設(shè)置長(zhǎng)緩存。但需注意：如果CDN地址不含版本號(hào)或哈希，不要對(duì)其設(shè)置永久強(qiáng)制緩存。

五、調(diào)試與驗(yàn)證工具箱

5.1 Chrome DevTools診斷清單

打開(kāi)Network面板，逐一檢查：

5.2 curl命令行驗(yàn)證

# 檢查響應(yīng)頭完整性
curl -sI https://example.com/app.a1b2c3.js | grep -iE 'cache-control|expires|vary'
# 預(yù)期輸出：
# Cache-Control: public, max-age=31536000, immutable
# Expires: Thu, 08 Jul 2027 02:42:00 GMT
# Vary: Accept-Encoding

5.3 Lighthouse審計(jì)

運(yùn)行Performance審計(jì)，重點(diǎn)關(guān)注：

• Serve static assets with an efficient cache policy：列出未設(shè)置長(zhǎng)緩存的靜態(tài)資源；
• Uses immutable caching：檢查帶哈希資源是否缺少immutable；
• Avoids excessive DOM size：間接反映緩存粒度是否合理。

六、常見(jiàn)踩坑速查表

七、結(jié)語(yǔ)

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

最新評(píng)論